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ABSTRACT 


The  phenomenon  of  “cloud  computing”  has  become  ubiquitous  among  users  of  the 
Internet  and  many  commercial  applications.  Yet,  the  U.S.  Navy  has  conducted  limited 
research  in  this  nascent  technology.  This  thesis  explores  the  application  and  integration  of 
cloud  computing  both  at  the  shipboard  level  and  in  a  multi-ship  environment.  A  virtual 
desktop  infrastructure,  mirroring  a  shipboard  environment,  was  built  and  analyzed  in  the 
Cloud  Lab  at  the  Naval  Postgraduate  School,  which  offers  a  potential  model  for  the 
foundation  of  a  cloud  computing  infrastructure  in  a  network  environment  aboard  ship. 
This  research  develops  a  Concept  of  Operations  to  propose  how  a  cloud  computing 
infrastructure  may  be  employed  and  how  it  might  operate  in  a  multi-ship  environment. 
This  thesis’  findings  indicate  that  cloud  computing,  when  combined  with  virtualization 
technologies,  can  improve  interoperability  via  the  loose  coupling  of  systems,  decrease 
network  footprints  via  server  consolidation,  and  increase  elasticity  of  resources. 
Additionally,  cloud  computing  may  alleviate  bandwidth  constraints  because  data  and 
information  in  a  cloud  network  can  be  stored,  shared,  and  accessed  locally.  This  could 
also  reduce  if  not  eliminate  reachback  through  satellites.  Future  efforts  in  this  area  of 
research  may  involve  more  rigorous  testing,  and  opportunities  toward  improved  security, 
as  well  as  leveraging  ever-improving  cloud  software. 
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I.  INTRODUCTION 


Cloud  computing  is  evolutionary  in  information  technology  and  revolutionary  as  a 
business  model.  Prominent  businesses  such  as  Amazon,  Facebook,  Google,  and 
Microsoft  have  adopted  cloud  computing  as  the  information  technology  model  for  many 
of  their  services.  Only  within  the  last  decade  has  the  U.S.  Federal  Government 
recognized  and  invested  in  cloud  computing,  promoting  the  movement  of  its  Federal  IT 
enterprises  to  a  cloud  model.  In  2010,  former  U.S.  Chief  Information  Officer  Vivek 
Kundra  listed  the  move  to  cloud  computing  as  point  number  three  of  the  “25  Point 
Implementation  Plan  to  Reform  Federal  Information  Technology  Management,” 
declaring  that  “beginning  immediately,  the  Federal  Government  will  shift  to  a  “Cloud 
First”  policy.”  [1] 

The  Department  of  Defense  and  the  Defense  Information  Systems  Agency  are 
actively  researching  cloud  computing  and  are  developing  cloud  computing  infrastructures 
in  some  of  their  shore  facilities,  connecting  to  and  becoming  part  of  the  Global 
Information  Grid  (GIG).  Though  cloud  computing  is  gaining  traction  in  government  IT 
infrastructures  ashore,  the  concept  of  implementing  cloud  computing  infrastructures  in 
afloat  environments  is  a  rather  nascent  idea.  In  fact,  the  Navy’s  acquisition  office  for 
command,  control,  communications,  computers,  and  intelligence  (C4I)  PEO-C4I  has 
requested  this  thesis  topic  to  help  them  with  concepts  for  cloud  computing  afloat.  This 
thesis  advocates  the  integration  of  cloud  computing  in  afloat  U.S.  Naval  network 
environments. 

A.  BACKGROUND 

The  current  afloat  network  infrastructure  on  a  U.S.  naval  vessel  uses  the  client- 
server  model.  In  a  client-server  model,  a  client  requests  services  from  a  server  and  a 
server  processes  the  requests  and  returns  the  results  to  the  client.  Typically,  in  an  IT 
enterprise  there  are  a  small  number  of  servers  fielding  requests  from  several  hundred  or 
several  thousand  clients. 
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An  Arleigh-Burke  class  destroyer  provides  an  example  of  a  naval  vessel  that  has  a 
small  IT  enterprise  using  the  client-server  model  in  an  afloat  network  environment. 
Within  the  ship  there  is  a  central  space  where  several  servers  are  located  (this  space  is 
usually  referred  to  as  the  “radio  room,”  or  just  “radio”).  Throughout  the  ship  are 
approximately  250  workstations.  Each  workstation  has  a  desktop  computer  (a  client)  that 
communicates  with  the  servers  over  a  network  using  Ethernet  cables.  Each  desktop 
computer  consists  of  a  monitor,  a  mouse,  a  keyboard,  and  a  mid-tower  computer  case 
containing  the  necessary  hardware  components  a  computer  needs  to  operate,  such  as  a 
processor,  memory,  a  hard  disk  drive,  and  a  network  card.  The  desktop  computers  also 
have  their  own  operating  system  and  software  programs  that  are  installed  on  the 
computer. 

Physical  resources  in  the  client-server  model  reside  primarily  in  desktop 
computers.  These  resources  are  rarely  ever  completely  used,  resulting  in  resources  that 
could  be  used  by  a  computer  in  need  of  additional  resources  elsewhere  on  the  network. 
Cloud  computing  is  a  solution  for  providing  the  access  to  these  resources  to  computers  in 
need  on  the  network.  This  is  accomplished  by  enabling  on  demand  access  to  shared 
resource  pools.  Virtualization,  currently  non-existent  in  afloat  network  environments,  is  a 
method  of  providing  scalable  desktop  computers  and  elastic  resources  when  used  as  the 
foundation  of  a  cloud  computing  infrastructure.  Cloud  computing,  combined  with 
virtualization,  transitions  away  from  the  client-server  model  to  a  model  in  which 
applications  are  no  longer  installed  and  executed  on  a  client  device.  Instead,  applications 
are  installed  and  executed  on  a  server,  streamed  over  a  network,  and  presented  to  a  user 
on  a  device  with  the  minimal  hardware  necessary  to  present  applications  (such  as  zero 
clients,  which  require  only  a  graphics  card  and  a  network  interface  card  (NIC). 

Moving  beyond  the  shipboard  level,  cloud  computing  infrastructures  may  also 
have  potential  benefits  in  large  scale  multi-ship  environments,  such  as  in  a  strike  group. 
While  afloat,  information  is  sent  to  a  ship  via  satellite  over  UHF,  SHF  or  EHF 
frequencies,  either  from  other  ships  or  from  shore  facilities.  Bandwidth  afloat  is 
increasingly  becoming  limited  and  as  a  result  throughput  to  afloat  naval  assets  is 
minimal,  connectivity  often  unreliable,  and  data  flow  sluggish  due  to  high-latency  in  the 

2 


satellite  links.  Cloud  computing  potentially  offers  tangible  benefits  to  alleviating 
bandwidth  constraints  by  utilizing  a  cloud  accessible  by  multiple  ships.  Given  the 
theoretical  possibility  that  a  strike  group  may  become  victim  to  a  satellite  denied 
environment,  a  cloud  shared  among  ships  may  be  a  suitable  alternative  for  sharing 
information  and  data. 

B.  PURPOSE 

The  U.S.  Navy  is  undergoing  vast  changes  in  its  computer  networks,  both  afloat 
and  ashore.  Planned  budget  cuts  may  cause  a  reduction  in  the  number  of  afloat  assets  and 
manpower.  The  Naval  Networks  Enterprise  of  2016  calls  for  the  reduction  or  elimination 
of  many  of  the  Navy’s  legacy  systems,  part  of  which  is  intended  to  reduce  costs  as  a 
means  of  meeting  budget  constraints. 

Cloud  computing  may  increase  bandwidth  efficiency  and  would  likely  reduce 
costs.  Virtual  technology  in  a  cloud  network  consolidates  disparate  resources  into  a  small 
number  of  central  servers,  allowing  multiple  users  to  access  resources  that  were  once 
spread  out  over  various  networks  and  systems.  Loose  coupling  of  systems  in  a  cloud 
computing  environment  allow  for  greater  interoperability  among  networks  and  systems, 
ultimately  leading  to  a  smaller  local  area  network  footprint  and  a  reduction  in  the  amount 
of  hardware  and  software  onboard  afloat  assets;  together  this  may  reduce  the  number  of 
manpower  needed,  resulting  in  cost  reduction.  Because  data  and  information  in  a  cloud 
network  can  be  stored,  shared,  and  accessed  locally  there  exists  the  potential  to  reduce 
bandwidth  usage.  Cloud  computing  infrastructures  integrated  in  afloat  network 
environments  have  the  potential  to  increase  the  elasticity  of  resources  and  would  bring 
data  to  the  tactical  edge,  reducing  if  not  eliminating  reach  back  through  satellites. 

C.  METHODS 

This  discovery  thesis  required  three  distinct  phases;  research,  experimentation, 
and  modeling.  The  research  phase  was  done  through  a  literature  review.  Experimentation 
was  conducted  by  building  an  actual  virtual  desktop  infrastructure  (VDI)  at  the  Naval 
Postgraduate  School  (NPS).  The  modeling  phase  explored  a  cloud  computing  concept  of 

operations  (CONOPS)  in  afloat  environments. 
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1. 


Literature  Review 


A  literature  review  was  carried  out  to  provide  knowledge  in  five  subject  areas 
specific  to  this  thesis.  The  first  subject  area  investigated  the  need  for  cloud  computing  in 
government  IT  infrastructures.  Specifically,  what  interests  the  DoD  has  in  cloud 
computing  and  the  goals  and  objectives  the  DoD  intends  to  achieve  using  cloud 
computing  technologies  and  infrastructures. 

The  second  subject  area  is  cloud  computing,  a  background  on  what  cloud 
computing  is  and  what  it  does  for  users  of  information  technology.  Common  cloud 
component  services  and  cloud  deployment  models  are  listed  and  defined. 

The  third  subject  area  researched  was  virtualization,  a  key  foundation  of  the  cloud 
computing  infrastructure  proposed  in  this  thesis.  Virtual  desktop  infrastructures  (VDI),  a 
relatively  new  method  of  offering  desktop  computers  to  users,  was  researched  in  order  to 
experiment  with  virtualization  in  the  Naval  Postgraduate  School’s  Cloud  Lab  and  to 
detennine  the  applicability  of  a  VDI  into  cloud  computing  infrastructures. 

The  fourth  subject  area  researched  and  identified  concepts  and  terms  common  in 
the  field  of  computer  networking,  such  as  service-oriented  architecture  (SOA)  and 
bandwidth  and  latency.  Popular  internet  and  VDI  protocols  are  explained  and  various 
client  devices  popular  in  VDI  and  cloud  infrastructures  are  discussed. 

The  last  subject  area  examined  current  DoD  network  programs  such  as  the 
Integrated  Shipboard  Network  System  and  Infonnation  Technology  for  the  21st  century, 
and  DoD  initiatives  such  as  Consolidated  Afloat  Networks  and  Enterprise  Services, 
which  is  under  development  by  PEO-C4I.  Identifying  and  researching  network  programs 
and  initiatives  allowed  for  the  assessment  of  how  current  enterprise  networks  in  afloat 
environments  operate,  the  capabilities  they  offer,  and  the  feasibility  of  integrating  cloud 
computing  into  afloat  environments. 

2.  Virtual  Desktop  Infrastructures 

The  experimentation  phase  of  this  thesis  involved  the  construction  of  a  VDI  in  the 
Cloud  Lab  at  the  Naval  Postgraduate  School  (NPS).  This  was  carried  out  in  three  steps, 


4 


the  first  being  the  identification  and  configuration  of  physical  computer  equipment  on 
which  to  build  a  VDI.  The  second  step  was  the  actual  building  of  a  VDI  using 
virtualization  software  products  by  VMware,  Inc.,  a  leader  in  commercial  off-the-shelf 
virtualization  technologies.  [2]  Testing  the  VDI  using  various  end  user  client  devices  was 
the  third  step.  Experimenting  with  a  VDI  allowed  for  a  first-hand  look  at  a  virtual 
infrastructure  as  a  possible  foundation  for  a  cloud  computing  infrastructure  in  afloat 
environments. 


3.  Cloud  Computing  Concept  of  Operations 

Modeling  a  cloud  computing  CONOPS  is  the  last  phase  of  this  thesis.  The 
CONOPS  ties  together  the  concepts  reviewed  in  the  literature  review  phase  with  the 
experimentation  of  the  VDI  in  the  second  phase  through  applying  them  to  afloat 
environments.  This  thesis  shows  it  is  possible  to  model  what  a  cloud  computing 
infrastructure  would  look  like  in  an  afloat  environment  by  understanding  the  concepts, 
definitions,  and  tenns  researched  in  the  literature  review  phase  and  by  applying  a  VDI  as 
built  in  the  NPS  Cloud  Lab. 

Modeling  a  cloud  infrastructure  is  best  achieved  through  the  development  of  a 
CONOPS  and  is  a  preliminary  step  required  in  the  systems  engineering  design  of  any 
system.  A  CONOPS  can  be  defined  simply  as  how  a  system  will  be  employed  and  how  it 
will  operate.  To  begin,  a  cloud  computing  infrastructure,  using  virtualization  as  a 
foundation  on  a  single  ship,  is  modeled.  Then,  the  scale  is  expanded  outward  beyond  the 
shipboard  level  to  a  multi-ship  environment,  such  as  a  strike  group,  and  offers  several 
possible  cloud  infrastructures  using  various  naval  assets  and  communication  methods. 

D.  STRUCTURE 

Following  the  current  chapter’s  introduction,  Chapter  II  draws  from  the  literature 
review  and  explains  the  concepts,  definitions,  and  terminology  relevant  to  this  thesis. 
Current  Navy  network  programs  and  initiatives  are  discussed  and  the  implications  and 
possibilities  they  present  regarding  their  potential  integration  with  cloud  computing 
infrastructures  are  examined. 
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Chapter  III  covers  the  step-by-step  process  that  was  taken  to  design  and  build  a 
VDI  in  the  Cloud  Lab.  The  virtualization  software  products  that  were  used  for  the  VDI 
are  described  and  the  features  they  offer  to  a  cloud  computing  infrastructure  are 
explained.  Though  the  majority  of  the  chapter  outlines  the  VDI  as  it  was  built  in  the 
Cloud  Lab,  the  end  of  the  chapter  provides  a  generic  approach  on  to  how  to  scale  this  and 
build  a  VDI  for  a  naval  asset  in  an  afloat  environment. 

Chapter  IV  presents  a  model  of  what  a  cloud  computing  infrastructure  would  look 
like  in  a  large  scale  multi-ship  afloat  environment.  A  cloud  computing  infrastructure 
based  on  virtualization  at  the  single  shipboard  level  is  presented  in  Chapter  III,  followed 
by  a  cloud  computing  infrastructure  in  a  large  scale  multi-ship  environment  in  Chapter 
IV.  This  is  achieved  by  developing  a  CONOPS  limited  in  scope,  specifically  determining 
what  a  cloud  computing  infrastructure  in  an  afloat  environment  would  look  like,  how  it 
would  be  employed,  and  how  it  would  operate.  Discussed  are  potential  communication 
methods  of  linking  clouds,  cloud  data  storage,  cloud-to-cloud  interoperability,  and  an 
afloat  cloud  command  and  control  structure. 

To  conclude,  Chapter  V  summarizes  the  thesis  and  restates  the  benefits  of  moving 
to  a  cloud  computing  infrastructure  in  afloat  environments.  Suggestions  for  further 
research  bring  the  chapter  and  the  thesis  to  a  close. 
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II.  LITERATURE  REVIEW 


This  chapter  lists  and  defines  various  concepts,  terms,  and  technologies  common 
in  the  field  of  computer  networking  and  in  cloud  computing.  The  Navy’s  current 
enterprise  network  programs  and  initiatives  are  also  examined  in  this  chapter. 

A.  CLOUD  COMPUTING 

The  term  cloud  computing  stems  from  the  ubiquitous  use  of  a  cloud  to  represent 
the  internet  as  depicted  in  a  network  diagram;  Figure  1  serves  as  a  simple  example. 


Figure  1.  Simple  network  diagram  depicting  a  cloud  as  the  Internet  [3] 

1.  Cloud  Computing  Defined 

Cloud  computing  is  the  modern  “buzzword”  used  to  describe  the  delivery  of 
computing  in  the  fonn  of  services  over  a  network.  Often,  a  user  or  company  does  not  own 
the  resources  or  the  equipment  on  which  the  services  reside,  but  instead  pays  for  the 
services  like  a  utility.  A  simple  analogy  is  an  electricity  grid.  A  user  of  electricity  does 
not  own  the  power  plant  where  the  electricity  is  produced,  nor  does  the  user  own  the 
power  lines  over  which  the  electricity  is  transmitted.  The  user  only  pays  for  the  amount 
of  electricity  used  over  a  given  period. 
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A  cloud  computing  infrastructure  operates  much  like  a  utility  company  when 
applied  to  a  network  environment.  But  instead  of  offering  electricity,  a  cloud  computing 
company  can  offer  computing  resources  such  as  data  storage  or  software  applications. 
The  hosting  company’s  resources  reside  on  their  computer  servers  in  a  remote  location. 
An  end  user  can  access  and  use  the  computing  resources  on  his  or  her  computer  device, 
such  as  a  desktop  computer  or  smart  phone. 

There  are  more  details  to  cloud  computing  than  the  example  just  given,  which  this 
thesis  will  show.  Cloud  computing  also  provides  an  enterprise  with  agility,  cost  savings, 
resource  elasticity,  and  scalability.  Defining  cloud  computing  can  be  difficult  and  many 
definitions  exist.  Two  of  the  most  prominent  and  widely  accepted  definitions  are  given 
below: 


a.  Defense  Information  Systems  Agency  (DISA) 

DISA  defines  cloud  computing  as  “a  means  of  enabling  convenient,  on- 
demand  network  access  to  a  shared  pool  of  configurable  computing  resources  (e.g.; 
networks,  servers,  storage,  applications  and  services)  that  can  be  rapidly  provisioned  and 
released  with  minimal  management  effort  or  service  provider  interaction.”  [4] 
Additionally,  DISA  lists  five  key  characteristics  of  cloud  computing:  On-Demand  Self 
Service,  Broad  Network  Access,  Resource  Pooling,  Rapid  Elasticity,  and  Measured 
Service.  [4] 


b.  National  Institute  of  Standards  and  Technology  (NIST) 

The  National  Institute  of  Standards  and  Technology  published  their  final 
definition  of  cloud  computing  in  September,  2011:  “Cloud  computing  is  a  model  for 
enabling  ubiquitous,  convenient,  on-demand  network  access  to  a  shared  pool  of 
configurable  computing  resources  (e.g.,  networks,  servers,  storage,  applications,  and 
services)  that  can  be  rapidly  provisioned  and  released  with  minimal  management  effort  or 
service  provider  interaction.  This  cloud  model  is  composed  of  five  essential 
characteristics,  three  service  models,  and  four  deployment  models.”  [5]  Like  DISA,  NIST 
lists  the  same  five  essential  characteristics:  On-Demand  Self  Service,  Broad  Network 

Access,  Resource  Pooling,  Rapid  Elasticity,  and  Measured  Service. 
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2.  Cloud  Computing  Component  Services 

Cloud  computing  can  further  be  defined  by  the  component  services  that  together 
form  a  typical  cloud  computing  infrastructure.  Figure  2  illustrates  the  components 
services  as  they  apply  in  a  cloud  computing  architecture.  Listed  below  are  the  most 
common  component  services  provided  in  a  cloud  computing  infrastructure. 

a.  In frastructure-as-a-Service 

The  most  basic  service  offering  in  a  cloud  infrastructure  is  Infrastructure- 
as-a-Service  (IaaS).  IaaS  provides  the  power,  storage,  networks  (including  IP  addresses), 
physical  computers,  and  virtual  machines  and/or  entire  virtual  infrastructures.  Amazon 
Elastic  Compute  Cloud  (EC2)  and  GoDaddy  are  two  of  the  most  popular  companies 
offering  IaaS  services.  NIST  defines  IaaS  as 

the  capability  provided  to  the  consumer  is  to  provision  processing,  storage, 
networks,  and  other  fundamental  computing  resources  where  the 
consumer  is  able  to  deploy  and  run  arbitrary  software,  which  can  include 
operating  systems  and  applications.  The  consumer  does  not  manage  or 
control  the  underlying  cloud  infrastructure  but  has  control  over  operating 
systems,  storage,  and  deployed  applications;  and  possibly  limited  control 
of  select  networking  components  (e.g.,  host  firewalls).  [5] 

b.  Platform-as-a-Service 

Platform-as-a-Service  (PaaS)  delivers  to  the  user  a  computing  platfonn 
and  provides  the  entire  infrastructure  needed  to  run  applications  over  a  network.  [6]  It  is  a 
platform  on  which  developers  can  build  custom  web  applications,  requiring  no 
downloading  or  installation  of  any  kind  for  the  end  user.  Simply  put,  PaaS  is  a  platform 
that  delivers  applications  over  a  network  (like  the  Internet).  Users  may  build  their  own 
applications  or  use  applications  already  built.  Google  App  Engine  and  Windows  Azure 
are  two  popular  companies  offering  PaaS  services.  PaaS  is  defined  by  NIST  as 

the  capability  provided  to  the  consumer...  to  deploy  onto  the  cloud 
infrastructure  consumer-created  or  acquired  applications  created  using 
programming  languages,  libraries,  services,  and  tools  supported  by  the 
provider.  The  consumer  does  not  manage  or  control  the  underlying  cloud 
infrastructure  including  network,  servers,  operating  systems,  or  storage, 
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but  has  control  over  the  deployed  applications  and  possibly  configuration 
settings  for  the  application-hosting  environment.  [5] 

c.  Software-as-a-Service 

The  ability  to  access  and  use  an  application  over  a  network  is  Software-as- 
a-Service.  Before  cloud  computing,  software  was  purchased  by  a  company  and  installed 
on  their  computers.  With  SaaS,  a  company  can  instead  use  the  software  as  necessary  over 
the  Internet  and  not  have  to  purchase  the  software.  Email  providers  like  Hotmail  and 
Gmail  are  examples  of  free  applications  hosted  as  a  SaaS  on  a  cloud  infrastructure. 
Unlike  PaaS,  applications  running  as  a  SaaS  are  not  open  for  development;  i.e.,  a 
platfonn  is  not  provided  for  application  development.  NIST  defines  SaaS  as 

the  capability  provided  to  the  consumer...  to  use  the  provider’s 
applications  running  on  a  cloud  infrastructure2.  The  applications  are 
accessible  from  various  client  devices  through  either  a  thin  client 
interface,  such  as  a  web  browser  (e.g.,  web-based  email),  or  a  program 
interface.  The  consumer  does  not  manage  or  control  the  underlying  cloud 
infrastructure  including  network,  servers,  operating  systems,  storage,  or 
even  individual  application  capabilities,  with  the  possible  exception  of 
limited  user-specific  application  configuration  settings.  [4] 


Cloud  Clients 

Web  browser,  mobile  app,  thin  client,  terminal 
emulator, ... 


< 


_2 


SaaS 

CRM,  Email,  virtual  desktop,  communication, 
games, ... 


PaaS 


Execution  runtime,  database,  Webserver, 
development  tools, ... 


laaS 


Virtual  machines,  servers,  storage,  load 
balancers,  network, ... 


Figure  2.  Cloud  computing  component  service  layers  [7] 
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d.  Desktop-as-a-Service 

Desktop-as-a-Service  is  the  delivery  of  hosted  desktop  services.  The 
desktops  are  typically  virtual  desktops  and  are  part  of  a  larger  VDI.  This  service  works  by 
delivering  a  virtual  desktop  over  a  network  to  an  end  user.  The  virtual  desktop  resides  on 
a  host  server  in  a  remote  location.  The  end  user  accesses  the  virtual  desktop  on  a  client 
device  (e.g.  a  desktop  computer,  a  laptop,  or  a  smart  phone).  Data  created  by  the  end  user 
is  saved  to  a  datacenter  where  the  host  server  resides.  This  service  is  similar  to  IaaS  in 
that  a  complete  user  desktop  is  streamed  over  a  network  by  a  host  server. 

3.  Cloud  Computing  Models 

There  are  three  primary  cloud  computing  models  (commonly  known  as 
“deployment  models”).  The  private  cloud,  the  public  cloud,  and  the  hybrid  cloud  are 
discussed  below. 


a.  Private  Cloud 

A  private  cloud  is  a  cloud  in  which  all  resources  reside  on  site  behind  an 
organization’s  firewall,  leaving  management  of  the  cloud  in  the  hands  of  the 
organization’s  IT  staff.  Reasons  for  a  private  cloud  are  security,  availability,  and 
reliability.  With  a  private  cloud  the  organization  purchases  and  maintains  all  of  the 
hardware  and  software. 

b.  Public  Cloud 

Public  clouds  are  the  most  common  cloud  models,  the  largest  being  the 
Internet.  These  clouds  contain  services  offered  to  the  general  public  and  are  owned  by 
organizations  renting  out  the  services  to  customers.  Services  are  offered  over  the  Internet 
via  web  applications  or  web  services.  Often,  companies  with  their  own  private  cloud  will 
connect  to  the  Internet  for  various  reasons  (e.g.,  email  exchange).  This  combination  of 
public  cloud  of  the  Internet  and  a  company’s  private  cloud  results  in  a  hybrid  cloud. 
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c.  Hybrid  Cloud 

A  hybrid  cloud  infrastructure  is  the  composition  of  two  different  types  of 
clouds,  such  as  the  combination  of  a  private  cloud  and  a  public  cloud.  The  individual 
clouds  within  a  hybrid  cloud  remain  unique  among  the  clouds  within  the  hybrid 
infrastructure,  “but  are  bound  together  by  standardized  or  proprietary  technology  that 
enables  data  and  application  portability  (e.g.,  cloud  bursting  for  load  balancing  between 
clouds).”  [5] 

B.  SERVICE-ORIENTED  ARCHITECTURE  (SOA) 

The  wide  use  of  standard  web  services  has  prompted  a  shift  in  IT  architectures  to 
an  architecture  based  on  services.  Service-oriented  architecture  attempts  to  address 
infonnation  systems  as  services  and  as  such  it  has  become  a  prominent  architecture  in  IT 
enterprises  and  it  has  also  become  a  programming  paradigm.  An  SOA  can  be  defined  as 

a  strategic  framework  of  technology  that  allows  all  interested  systems, 
inside  and  outside  of  an  organization,  to  expose  and  access  well-defined 
services,  and  infonnation  bound  to  those  services,  that  may  be  further 
abstracted  to  process  layers  and  composite  applications  for  solution 
development.  [8] 

SOA  depends  on  the  loose  coupling  of  devices,  the  ability  of  a  service  to  be 
interoperable  with  another  service  even  if  the  services  have  no  knowledge  of  the 
definitions  of  each  other;  the  services  only  need  to  be  able  to  logically  recognize  the 
other.  This  method  of  loose  coupling  and  interoperability  between  services  is  also 
common  in  cloud  computing  architectures. 

Like  cloud  computing,  SOA  operates  on  a  paradigm  in  which  services  are  at  its 
core.  Also  similar  to  cloud  computing  are  many  of  the  characteristics  in  a  SOA,  including 
agility,  granularity,  interoperability,  modularity,  and  reuse.  The  relationship  between 
cloud  computing  and  SOA  is  that  cloud  computing,  which  provides  IT  resources  capable 
of  being  leveraged  on  demand,  is  a  suitable  IT  infrastructure  on  which  a  SOA  can 
operate.  SOA  is  a  “good  approach  to  architecture  that  deals  with  the  proper  formation  of 
the  information  systems  using  mechanisms  that  make  them  work  and  play  well  together.” 


12 


[8]  Thus,  when  combined  with  cloud  computing,  SOA  supplies  an  enterprise  with  the 
interfaces  and  architecture  that  link  the  enterprise  with  cloud  services. 

Simply  put,  SOA  and  cloud  computing  complement  each  other.  An  IT  enterprise 
built  on  cloud  computing  requires  governance,  which  includes  policies  and  the  right 
management  tools;  SOA  provides  such  governance.  Cloud  computing  is  an  instance  of  an 
architecture,  whereas  SOA  is  a  pattern  of  architectures.  In  sum,  “SOA  is  more  holistic 
and  strategic,  meaning  it  deals  with  the  complete  enterprise  including  business  drivers, 
whereas  cloud  computing  is  more  tactical  and  is  a  way  of  solving  a  problem.”  [8]  An 
enterprise  successfully  integrating  SOA  and  cloud  computing  is  likely  to  be  more 
effective  and  efficient  than  an  enterprise  that  does  not.  [8] 

C.  VIRTUALIZATION 

Virtualization  is  the  partitioning  of  physical  resources  into  multiple  virtual 
machines.  An  example  is  the  partitioning  of  a  hard  drive  in  order  to  allocate  virtual 
storage  to  virtual  machines,  or  the  division  of  a  physical  server  into  multiple  virtual 
servers.  Virtualization  is  an  enabler  of  resource  sharing  and  resource  allocation.  In  a 
cloud  computing  infrastructure  virtualization  offers  scalability,  greater  agility  of  services, 
elasticity  of  resources,  and  improved  infrastructure  utilization.  [9]  Almost  every 
component  of  IT  can  be  virtualized,  including  servers,  desktops,  applications,  local  area 
networks,  switches,  routers,  firewalls,  and  more. 

Server  virtualization  is  key  to  the  consolidation  of  physical  servers,  which  results 
in  a  reduction  in  an  enterprises’  datacenter  footprint  and  in  costs  savings  via  a  reduction 
in  the  number  of  server  hardware.  Once  server  virtualization  has  been  implemented  a 
single  physical  server  can  then  support  multiple  virtual  machines  (VM).  Figure  3  shows  a 
typical  server  virtualization  structure,  with  the  ability  to  scale  to  multiple  virtual 
machines. 
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Application  N 

Guest  OS  1 
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Guest  OS  N 
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Physical  Machine 

Figure  3.  Server  Virtualization  [9] 


In  addition  to  server  virtualization,  virtual  local  area  networks,  VMs,  and  virtual 
machine  monitors  (also  known  as  hypervisors)  are  a  few  of  the  most  common  virtual 
technologies. 

1.  Virtual  Local  Area  Network 

A  virtual  local  area  network  (VLAN)  replicates  a  physical  LAN  in  that 
multiple  hosts  are  linked  together  to  form  a  network.  VLANs  have  the  same  attributes 
found  in  a  physical  LAN,  but  end  user  devices  can  be  grouped  together  on  one  physical 
machine  or  server  via  multiple  network  switches  vice  multiple  physical  locations  sharing 
a  single  switch.  [10]  Though  VLANs  do  not  require  the  hardware  (cables,  switches,  etc.) 
a  physical  LAN  would,  they  do  consume  bandwidth  from  the  network  the  VLAN  is 
connected  to. 

2.  Virtual  Machine 

A  virtual  machine  is  an  isolated  software  application  that  runs  its  own 
operating  systems  and  applications,  acting  like  a  physical  computer.  [10]  It  contains  its 
own  virtual  processor,  RAM,  hard  disk  drive,  and  NIC.  Operating  systems  and  other 
computers  on  a  network  cannot  tell  the  difference  between  a  virtual  machine  and  a 
physical  machine.  Applications  that  run  on  a  physical  computer  can  run  on  a  virtual 
machine. 
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3.  Hypervisor 

A  virtual  machine  monitor,  or  hypervisor,  is  the  foundation  of  hardware 
virtualization  and  allows  multiple  operating  systems  to  run  on  a  computer.  A  hypervisor 
is  the  core  (kernel)  of  a  virtualization  platform.  It  is  installed  on  the  physical  server’s 
hardware  and  serves  as  a  virtual  operating  platform  for  multiple  virtual  operating 
systems.  Its  sole  purpose  is  to  run  virtual  operating  systems.  In  terms  of  cloud  computing 
it  is  a  function  of  IaaS. 

Hypervisors  simplify  the  management  of  virtual  machines  via  controlling 
resources  by  allocating  what  is  needed  to  each  operating  system  residing  on  the  layer 
above  the  hypervisor.  Hypervisors  that  run  directly  on  top  of  a  physical  server’s  hardware 
are  known  as  “bare-metal”  hypervisors,  or  “Type-1”  hypervisors.  Figure  4  depicts  an 
example  of  a  Type-1  Hypervisor,  with  the  hardware  layer  on  bottom  and  the  virtualized 
OS  and  applications  above. 


VM1 

VM2 

Applications 

Applications 

Type-1  Hypervisor 


Hardware  (CPU,  Memory,  Interrupts) 

Figure  4.  A  Type-1  Hypervisor  [11] 

4.  Paravirtualization 

Virtualization  requires  that  an  entire  system  be  emulated  (BIOS,  processor,  NIC). 
A  more  efficient  use  of  resources  lies  in  a  specific  type  of  virtualization,  called 
paravirtualization.  With  paravirtualization,  multiple  operating  systems  can  run  on 
hardware  at  the  same  time,  just  like  with  virtualization.  The  key  difference  lies  in 
resources  sharing,  which  paravirtualization  does  more  efficiently  because  it  does  not 
emulate  an  entire  system,  but  rather  only  certain  abstractions.  Generally,  an  operating 
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system  performs  better  using  paravirtualization  vice  full  virtualization;  however, 
flexibility  is  lost  and  security  is  reduced  when  using  paravirtualization  given  that  the  OS 
may  not  be  readily  available  for  the  required  abstraction  and  that  the  OS  has  greater 
access  to  the  underlying  hardware.  [12]  As  will  be  discussed  later,  the  virtualization  used 
in  the  NPS  Cloud  Lab  and  the  virtualization  advocated  for  integration  into  afloat  cloud 
computing  infrastructures  is  full  virtualization. 

D.  BANDWIDTH  AND  LATENCY 

Bandwidth  and  latency  are  data  transmission  characteristics.  The  terms  have 
different  meanings  in  different  fields  of  study.  In  this  section  they  are  defined  as  they 
apply  to  the  field  of  computer  networking. 

1.  Bandwidth 

Generally  speaking,  bandwidth  is  the  measure  of  the  amount  of  information  that 
can  be  transmitted  over  a  communications  medium.  For  example,  the  optical  carrier 
classification  OC-1  is  capable  of  transmitting  51.84  Mbps  on  optical  fiber.  [15]  In  other 
words,  the  OC-1  optical  fiber  has  a  bandwidth  of  51.48  Mbps.  More  ascribable  to  afloat 
environments  is  the  bandwidth  provided  by  satellite  communications.  For  example,  the 
Defense  Satellite  Communications  System  (DSCS),  which  uses  the  SHF  medium,  has  a 
typical  bandwidth  allocating  between  4Mbps  and  5.5Mbps  per  satellite  footprint,  but  only 
256Kbps  to  2.048Mbps  are  allocated  to  afloat  units.  [12]  Other  afloat  assets  have  even 
lower  bandwidth. 

Bandwidth  is  highly  important  to  afloat  units  because  they  are  constrained  to  a 
very  limited  amount  of  bandwidth  while  at  sea.  Increase  in  bandwidth  is  almost  always 
the  number  one  reason  for  technology  upgrades  to  old  communications  satellite  programs 
and  new  defense  satellite  programs  are  always  aimed  at  increasing  bandwidth  to  afloat 
units.  Cloud  computing  infrastructures  may  alleviate  bandwidth  constraints  at  sea  by 
reducing  or  eliminating  the  need  for  information  to  travel  via  satellite  between  afloat 
units. 
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2.  Latency 

Latency  is  a  measurement  of  time,  referring  specifically  to  the  delay  between  the 
transmission  of  a  signal  and  its  eventual  receipt.  [14]  As  distance  increases  between  two 
devices,  so  too  does  the  latency.  Likewise,  as  bandwidth  decreases,  the  amount  of  time  it 
takes  for  information  to  reach  its  destination  increases.  This  situation  is  exacerbated  when 
large  amounts  of  data  are  being  sent  over  a  medium  with  small  bandwidth,  a  scenario 
common  in  afloat  environments. 

Potential  errors  can  occur  due  to  latency  if  data  sent  is  not  received  over  a  given 
period.  For  example,  a  receiving  node  expects  a  communication  over  a  certain  time 
frame.  The  node  may  assume  it  has  received  all  of  the  data  in  the  communication  when 
the  time  frame  has  expired,  although  more  data  may  still  be  en  route.  Figure  5  illustrates 
the  effect  distance  has  on  bandwidth  and  latency. 
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Figure  5.  The  effect  on  bandwidth  and  latency  as  distance  increases  [15] 
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E. 


COMMON  INTERNET  PROTOCOLS 


A  multitude  of  logical  communications  protocols  exist  in  computer  networking. 
The  most  common  are  those  that  comprise  the  Internet  Protocol  Suite  and  enable  the 
transfer  of  information  between  computers  on  the  Internet  and  on  intranets.  IP  (Internet 
Protocol),  HTTP  (Hypertext  Transfer  Protocol),  and  FTP  (File  Transfer  Protocol)  are 
examples  of  the  most  popular  protocols.  IP  is  the  primary  method  of  transmitting  data 
across  networks.  HTTP  is  the  foundation  of  and  primary  method  of  transferring  data 
across  the  World  Wide  Web.  FTP  is  the  standard  method  of  transferring  files  between 
hosts.  Computers  will  use  either  the  TCP  (Transmission  Control  Protocol)  or  UDP  (User 
Datagram  Protocol)  protocol  to  transfer  infonnation  between  a  server  and  remote  clients 
on  a  network.  [15]  Both  protocols  have  their  own  unique  benefits  and  are  discussed 
below. 


1.  Transmission  Control  Protocol 

Transmission  Control  Protocol  is  a  connection  oriented  protocol  and  focuses  on 
reliability  and  accuracy  in  the  delivery  of  “packets”  (packets  are  the  units  that  carry  data 
across  networks).  This  is  accomplished  via  a  three-way  handshake.  For  example,  before 
data  is  sent  a  server  will  initiate  a  transmission  by  sending  a  synchronization  packet 
request  to  a  client  device.  The  client  device  will  respond  with  a  synchronization- 
acknowledge  packet  (a  confirmation  packet).  The  initiating  device  (the  server)  then 
responds  with  an  acknowledge  packet,  establishing  a  connection.  Once  the  connection 
has  been  established,  the  initiating  device  is  free  to  deliver  its  data.  This  exchange 
illustrates  the  guarantee  that  data  is  being  received  by  the  client  device  given  that  a 
connection  was  first  established.  Though  TCP  provides  reliability,  latency  increases  as  a 
result  because  of  the  three-way  handshake. 

2.  User  Datagram  Protocol 

User  Datagram  Protocol  is  a  connectionless  oriented  protocol  that  focuses  less  on 

reliability  and  more  on  the  speedy  delivery  of  “datagrams”  (datagrams  are  the  units  that 

carry  data  across  networks,  similar  to  the  packets  in  the  TCP  protocol).  With  UDP  there 

is  no  handshake  or  guarantee  of  delivery.  Datagrams  are  simply  sent  one-way  over  a 
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network.  Thus,  UDP  is  a  more  efficient  method  of  delivering  infonnation  and  reducing 
latency,  but  it  lacks  the  reliability  found  in  TCP.  Due  to  the  nature  of  its  efficiency  in 
speed,  UDP  is  the  preferred  method  in  transmitting  large  volumes  of  information  that  is 
time-sensitive.  Video,  VTC,  and  live  audio  transmissions  in  particular  benefit  from  UDP. 

F.  COMMON  VDI  PROTOCOLS 

Protocols  used  to  exchange  information  on  a  VDI  are  designed  to  provide  a  user 
with  a  graphical  user  interface  (GUI).  This  is  because,  in  a  VDI,  processes  are  being 
executed  on  the  servers  in  a  datacenter  and  not  at  the  client  device.  A  user  only  needs  to 
interact  with  the  presentation  of  applications  on  a  client  device  (monitor,  smart  phone, 
etc.).  Remote  Desktop  Protocol  and  Personal  Computer  over  Internet  Protocol  are  two 
common  VDI  protocols. 

1.  Remote  Desktop  Protocol 

The  Remote  Desktop  Protocol  (RDP)  is  a  protocol  developed  by  Microsoft. 
Designed  to  support  different  types  of  network  topologies  and  LAN  protocols,  RDP 
provides  remote  display  and  input  capabilities  over  network  connections.  [16]  Users  on  a 
remote  client,  such  as  a  zero  client,  connect  to  a  server  or  VM  via  RDP.  Connection 
initialization,  capabilities  negotiation,  and  the  transfer  input  between  a  remote  client  and 
a  server  are  specific  functions  of  RDP.  [17] 

Devices  using  RDP  send  infonnation  using  TCP,  ensuring  data  integrity.  When 
viewing  video  files,  however,  it  is  often  the  case  a  user  will  experience  a  mismatch  in  the 
synchronization  of  the  audio  with  the  video.  Video  feeds  and  VTCs  are  becoming  more 
popular  on  afloat  units  as  bandwidth  increases  with  every  new  generation  of  satellites. 
Thus,  RDP  may  not  always  be  suitable  for  data  transmission  on  networks  at  sea, 
particularly  in  a  VDI  environment.  A  solution  may  be  in  the  Personal  Computer  over 
Internet  Protocol. 

2.  Personal  Computer  over  Internet  Protocol 

Personal  Computer  over  Internet  Protocol,  or  PCoIP,  is  a  proprietary  protocol 
owned  by  the  Teradici  Corporation  and  is  a  relatively  new  method  of  delivering  a  desktop 
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over  internet  protocol.  Based  on  display  compression,  the  PCoIP  protocol  “compresses, 
encrypts,  and  encodes  the  entire  computing  experience  at  the  data  center  and  transmits  it 
‘pixels  only’  across  any  standard  IP  network  to  stateless  PCoIP  zero  clients.”  [18] 

The  design  of  PCoIP  is  intended  to  “deliver  a  user’s  desktop  from  a  centralized 
host  PC  with  an  immaculate,  uncompromised  end-user  experience  across  standard  IP 
networks;  including  full  DVI  dual  monitor  video,  complete  USB  compatibility,  and  high- 
definition  audio.”  [19]  Characteristics  of  PCoIP  include  optimization  for  minimal 
bandwidths  for  low  bandwidth  situations;  use  of  existing  IP  networks;  compatibility  with 
all  operating  systems;  compatibility  with  all  PC  applications;  and  the  ability  to  adapt  to 
changing  network  conditions  and  use  less  bandwidth  when  a  network  is  congested.  [19] 

Devices  using  PCoIP  send  infonnation  using  either  TCP  or  UDP.  This  can  be 
advantageous  depending  on  what  type  of  data  is  being  sent  over  a  network.  In  situations 
where  large  volumes  of  data  are  being  transmitted,  such  as  in  a  VTC,  then  the  option  to 
select  UDP  is  very  beneficial. 

G.  THICK  CLIENTS,  THIN  CLIENTS,  AND  ZERO  CLIENTS 

There  are  three  types  of  client  devices  in  client-server  architectures;  thick  clients, 
thin  clients,  and  zero  clients.  The  differences  between  each  of  them  and  their  advantages 
and  disadvantages  are  discussed  below. 

1.  Thick  Clients 

Typical  network  enterprises,  particularly  those  that  do  not  implement  cloud 
architectures,  use  thick  clients.  A  thick  client  (also  called  a  “fat  client”)  is  a  complete 
computer  desktop,  equipped  with  the  necessary  hardware  components  to  run  applications 
on  the  computer.  This  type  of  client  is  typical  of  client-server  networks  and  functions  for 
the  most  part  independent  of  a  central  server.  A  thick  client  has  installed  on  it  its  own  OS 
and  applications  and  processes  are  executed  on  the  client  and  data  is  stored  locally  on  the 
client.  Downsides  of  thick  clients  are  that  they  must  be  managed  individually  and  their 
resources  are  not  elastic  across  a  network. 


20 


2. 


Thin  Clients 


Thin  clients  are  slimmed  down  versions  of  thick  clients,  containing  only  the  bare 
minimum  hardware  components  necessary  to  present  applications  via  a  GUI.  A  thin 
client  has  installed  on  it  its  own  OS  or  at  a  minimum  the  software  necessary  for  the  thin 
client  to  operate,  but  applications  reside  on  a  server  connected  to  the  thin  client.  Thus,  a 
thin  client  is  server  dependent;  most  processes  are  executed  on  the  server  and  data  is 
stored  on  the  server  or  at  a  remote  location  (other  than  the  thin  client).  A  thin  client  is 
designed  to  be  a  low-end  terminal,  and  as  such  little  management  is  required  of  the 
device  itself.  Thin  clients  also  practice  resource  elasticity,  given  they  only  use  what  they 
need  from  the  resources  supplied  over  the  network  by  remote  servers  in  a  datacenter.  (A 
datacenter  is  simply  a  facility  or  area  in  one  of  an  organization’s  buildings  that  houses  the 
primary  processing  computers  and  data  storage  of  an  organization’s  IT  enterprise.) 

3.  Zero  Clients 

Zero  clients  are  small  in  size,  as  the  name  would  suggest,  and  do  not  contain  an 
OS,  a  CPU,  or  memory.  A  display  adaptor  and  a  NIC  are  typically  the  only  hardware 
components  in  a  zero  client.  Zero  clients  can  be  defined  as  a  device  that  “only  connects  a 
monitor  and  peripherals  (mouse,  keyboard,  USB  devices)  back  to  a  VDI  or  similar 
infrastructure  in  the  data  center.”  [20]  All  processing  and  storage  is  done  at  the  servers  in 
the  data  center,  making  the  zero  client’s  sole  purpose  the  presentation  of  applications  via 
a  GUI. 

Given  the  nature  of  their  design,  zero  clients  are  optimal  end  user  devices  in  a 
VDI.  In  a  network  environment  using  a  VDI,  benefits  of  zero  clients  include  lower 
operating  costs  and  easier  management  and  deployment.  [20]  Like  thin  clients,  zero 
clients  also  use  only  the  resources  they  need,  enabling  resource  elasticity. 

H.  DOD  ENTERPRISE  NETWORK  PROGRAMS  AND  INITIATIVES 

The  U.S.  Navy  operates  several  enterprise  networks  both  on  land  and  at  sea.  In 
2011  the  Naval  Enterprise  Networks  (NEN)  Program  Office  (PMW205)  was  established 
to  manage  the  Navy’s  three  largest  enterprise  networks;  the  OCONUS  Navy  Enterprise 
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Network  (ONE-NET),  the  Navy-Marine  Corps  Intranet  (NMCI),  and  the  Next  Generation 
Enterprise  Network  (NGEN).  These  Programs  of  Record  are  shore  based  enterprise-wide 
IT  networks  that  offer  end-to-end  infonnation  and  telecommunication  services.  They 
provide  common  computing  environments  for  both  the  Non-secure  IP  Router  Network 
(NIPRNet)  and  the  Secure  IP  Router  Network  (SIPRNet).  [21]  Currently,  none  of  these 
enterprise  networks  utilize  cloud  computing  infrastructures.  (PEO-C4I  is  looking  into 
integrating  cloud  computing  into  Navy  enterprise  networks  and  is  discussed  at  the  end  of 
this  chapter). 

Enterprise  networks  afloat  include  the  Integrated  Shipboard  Network  System 
(ISNS)  and  Information  Technology  for  the  Twenty-First  Century  (IT-21).  These  afloat 
network  systems  also  do  not  use  cloud  infrastructures.  They  are  discussed  below. 

1.  Integrated  Shipboard  Network  System 

The  Integrated  Shipboard  Network  System  is  a  ship’s  primary  LAN 
infrastructure.  Both  secret  and  unclassified  networks  are  provided  by  ISNS.  In  addition  to 
a  network  infrastructure,  basic  network  information  distribution  services  are  also 
provided.  Operating  on  a  client-server  model,  ISNS  is  the  backbone  of  an  afloat  unit’s 
network  infrastructure  and  is  an  integral  part  of  IT-21.  Considered  a  legacy  system,  ISNS 
is  one  of  many  IT  systems  expected  to  be  consolidated  into  the  Navy  PEO-C4I’s 
Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES)  initiative,  discussed 
later  in  this  section. 

2.  Information  Technology  for  the  Twenty-First  Century 

IT-21  was  established  after  the  introduction  of  Transmission  Control 
Protocol/Intemet  Protocol  (TCP/IP)  on  afloat  units  became  the  standard  method  of 
sending  and  receiving  data.  An  infonnation  transfer  strategy,  IT-21  is  a  “formalization  of 
architecture  and  capabilities  to  provide  TCP/IP  services  to  afloat  units.”  [14]  IT-21 
provides  IP  network  connectivity  capable  of  data,  video,  and  voice,  and  provides  access 
to  NIPRNet,  SIPRNet,  and  other  Navy  intranets  between  afloat  units.  IT-21  also  supports 
internet  chat  relay  programs  such  as  Microsoft  Chat  (MS  Chat)  and  mIRC,  which  became 


22 


prevalent  in  the  fleet  after  TCP/IP  was  accepted  as  the  preferred  method  for  coordination 
between  afloat  units. 

To  communicate  off  ship  to  other  afloat  units  or  shore  installations  IT-21  uses 
approved  acquisition  programs.  These  programs  include,  but  are  not  limited  to,  the  SHF 
based  Commercial  Wideband  Satellite  Program  (CWSP),  the  SHF  based  Defense 
Satellite  Communications  System  (DSCS),  and  the  EHF  based  Military  Strategic  Relay 
Satellites  (MILSTAR). 

IT-21  implementation  into  the  fleet  began  in  the  early  2000’s  and  the  program  is 
currently  comprised  of  over  60  legacy  networks.  The  legacy  systems  and  the  technology 
supporting  IT-21  have  become  operationally  obsolete  and  are  expected  to  be  replaced  by 
the  CANES  initiative. 

3.  Consolidated  Afloat  Networks  and  Enterprise  Services 

The  Consolidated  Afloat  Networks  and  Enterprise  Services  initiative,  under 
development  by  PEO-C4I,  will  provide  a  common  computing  environment  on  afloat  units 
and  is  expected  to  replace  and/or  consolidate  several  of  the  Navy’s  aging  network 
programs  (see  Figure  6),  such  as  the  Combined  Enterprise  Regional  Infonnation 
Exchange  (CENTRIXS),  ISNS,  IT-21,  Submarine  Local  Area  Network  (SUBLAN),  and 
SCI  networks.  A  primary  function  of  CANES  will  be  to  provide  a  single  support 
framework  for  C4I  applications.  According  to  PEO-C4I,  “CANES  will  take  advantage  of 
the  new  business  model  of  open  architecture,  Service  Oriented  Architecture  (SOA),  and 
rapid  COTS  insertion,  in  order  to  bring  fiscal  savings  to  the  Navy,  as  well  as  operational 
agility  to  the  warfighter.”  [22]  The  PEO-C4I  Masterplan  of  2012  states  that  CANES  will 
reach  full  deployment  on  surface  platfonns  by  2021.  [23] 
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Networks  +  ADNS  +  Services 


Figure  6.  Consolidation  of  legacy  networks  into  CANES  [24] 


Furthennore,  CANES  is  an  effort  for  “reducing  server  footprints  and  migrating 
existing  shipboard  hardware  into  a  centralized,  managed  process,  replacing  ISNS  and 
parts  of  IT-21.  It  will  also  provide  the  Fleet  with  an  ability  to  collaborate  and  share 
information  across  the  warfighter  domain  with  reach-back  to  the  assisting  shore 
establishments.”  [25]  These  objectives  will  be  met  by  the  implementation  of  two 
subprograms,  the  Common  Computing  Environment  (CCE)  and  the  Afloat  Core  Services 
(ACS).  The  CCE  is  considered  the  hardware  portion  of  CANES  and  the  ACS  represents 
the  software  portion  of  CANES. 

The  primary  goals  of  CANES  are  to  “1)  reduce  the  number  of  networks  through 
the  use  of  mature,  certified,  cross  domain  technologies;  2)  reduce  the  infrastructure 
footprint  and  associated  costs  for  hardware  afloat;  and  3)  provide  increased  capability  to 
meet  current  and  projected  warfighter  requirements.”  [26]  Additionally,  CANES  will 
decouple  applications  and  services  software  from  independent  hardware  stacks,  and 
instead  they  will  be  hosted  on  a  common  interoperable  environment.  [26] 

The  integration  of  SOA  and  the  consolidation  of  legacy  systems  are  big  steps 
towards  a  cloud  computing  architecture.  The  focus  on  delivering  services  and  the 
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decoupling  of  hardware  and  software  are  characteristics  of  CANES,  and  it  is  these  same 
characteristics  that  are  also  at  the  core  of  what  cloud  computing  offers  an  enterprise. 
CANES,  however,  will  not  be  using  a  cloud  computing  architecture;  but,  it  does  stand  as 
a  precursor  to  cloud  computing.  Should  cloud  computing  eventually  be  integrated  into 
afloat  network  environments,  much  of  the  necessary  foundation  will  already  be  in  place 
given  that  CANES  is  built  on  a  SOA.  As  stated  earlier,  SOA  and  cloud  computing  are 
complementary  to  each  other.  Therefore,  the  advocacy  for  the  integration  of  cloud 
computing  into  afloat  enterprise  networks  is  both  appropriate  and  applicable  given  the 
SOA  design  of  CANES  and  the  implementation  of  CANES  in  the  very  near  future. 

The  Navy  is  aware  of  the  tangible  benefits  of  cloud  computing,  as  is  evident  in  the 
request  by  PEO-C4I  to  define  a  technical  framework  for  cloud  computing  at  the  tactical 
edge.  (Cloud  computing  is  an  NPS  thesis  area  of  interest  for  PEO-C4I,  as  well.)  In  the 
Framework  for  Cloud  Computing  at  the  Tactical  Edge  report  [27],  three  strategic 
challenges  are  listed: 

•  How  to  govern,  manage,  process,  and  exploit  dramatic  increases  in  C4ISR 
data  ashore  and  afloat 

•  How  to  boost  IT  efficiency/utilization  while  lowering  costs 

•  How  to  align  IT  acquisition  with  fleet  operational  needs  and  rapidly 
deliver  incremental  capabilities 

To  address  these  strategic  challenges,  PEO-C4I  suggests  using  cloud  computing 
and  is  researching  the  integration  of  cloud  computing  into  the  US  Navy.  The  Framework 
for  Cloud  Computing  at  the  Tactical  Edge  report  specifically  discusses  “architectural 
considerations,  an  operational  concept,  and  content  distribution  management  within  the 
Navy’s  C4ISR  afloat/ashore  environments.”  [27]  A  portion  of  this  report  is  examined 
further  in  Chapter  IV  to  address  cloud  data  storage  afloat.  [27] 
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III.  VIRTUALIZATION  MODELS 


The  foundational  building  block  of  the  cloud  computing  model  for  afloat 
shipboard  networks  presented  in  this  thesis  is  virtualization.  Virtualization  eliminates  the 
one-server,  one-application  model  and  replaces  the  client-server  model  with  a  virtual 
desktop  infrastructure  (VDI).  In  a  VDI  conventional  desktop  computers  are  replaced  with 
thin  or  zero  clients.  A  thin  client  or  zero  client,  which  contain  very  little  hardware,  are 
what  provides  a  user  with  a  GUI  on  which  to  access  a  virtual  machine  (VM).  VMs  reside 
on  a  host  computer  over  a  network.  Hosts,  which  are  typically  servers,  can  have 
thousands  of  virtual  machines.  A  VDI,  when  coupled  with  cloud  computing  services,  is  a 
powerful  enterprise  level  infrastructure  capable  of  leveraging  elastic  resources. 

Benefits  of  virtualization  include  datacenter  automation,  a  reduction  in  capital 
costs  by  increasing  energy  efficiency,  maximization  of  hardware  resources,  and  ease  of 
enterprise  desktop  management.  [28]  Additionally,  administrators  can  focus  on  one 
physical  machine  that  hosts  a  multitude  of  virtual  machines  vice  having  to  manage 
multiple  servers  and  hundreds  or  thousands  of  physical  desktop  computers  throughout  an 
organization. 

The  cloud  computing  infrastructure  as  envisioned  in  a  shipboard  environment  in 
this  thesis  is  not  possible  without  the  implementation  of  virtualization  because  the 
creation,  replication,  and  distribution  of  virtual  machines  to  end  users  would  not  be 
possible.  Currently,  shipboard  IT  and  network  infrastructures  onboard  ships  operate  on  a 
client-server  model,  generally  with  one  room  (radio)  containing  the  central  servers  that 
process  and  store  all  data  on  a  ship,  with  various  smaller  sized  servers  scattered 
throughout  the  ship  that  run  specific  applications.  Depending  upon  the  size  of  the  ship 
there  can  be  several  hundred  or  several  thousand  desktop  computers  and/or  laptops. 
These  desktop  computers  contain  their  own  hardware,  such  as  a  processor,  a  HDD,  a  CD- 
ROM  drive,  a  NIC  card,  etc.,  and  rely  on  the  shipboard  network  for  connectivity  to  the 
servers. 


27 


Often,  it  is  the  case  that  the  hardware  in  the  desktop  computers  and  servers  are  not 
used  to  its  full  potential.  Virtualization  allows  for  maximizing  the  potential  use  of 
hardware  resources  that  would  otherwise  go  unused  or  become  underutilized. 
Maximizing  physical  resources  is  one  of  the  prime  benefits  of  virtualization. 
Additionally,  virtualization  helps  consolidate  physical  resources  and  it  can  isolate  servers 
from  each  other  while  operating  on  the  same  physical  server.  This  is  achieved  by  creating 
a  virtualization  layer  and  virtual  servers. 

Once  a  virtualization  layer  has  been  created,  the  hardware  can  be  partitioned  and 
assigned  to  discrete  virtual  operating  systems.  These  virtual  operating  systems  operate 
independently  of  each  other  and  are  unaware  other  OSs  exist  on  the  same  physical 
machine.  The  virtualization  layer  allows  for  administrators  to  easily  control  and  configure 
the  VDI.  Resource  pooling  solves  the  issue  of  underutilized  hardware,  and  it  is  easily 
managed  by  administrators  without  having  to  take  a  physical  server  offline.  For  example, 
if  it  has  been  detennined  that  one  of  many  virtual  servers  does  not  maximize  its  potential 
of  allocated  resources,  then  those  resources  may  be  transferred  to  another  server  in  need 
of  those  resources  by  changing  the  configuration  without  taking  offline  the  physical 
server  on  which  the  virtual  server  resides.  If  a  physical  server  needs  to  be  taken  offline 
for  maintenance  or  repairs,  then  the  virtual  servers  residing  on  that  physical  server  can  be 
moved  seamlessly  to  another  physical  server.  This  can  be  done  manually  or  configured  to 
be  done  automatically. 

The  virtualization  software  that  was  used  for  this  thesis  is  VMware.  [29]  VMware 
is  a  frontrunner  in  the  virtualization  industry  and  has  pioneered  many  of  the  virtualization 
products  available  on  the  market.  Their  software  can  run  on  the  most  common  operating 
systems,  such  as  Windows,  Linux,  and  Mac  OS  X,  while  their  enterprise  software 
hypervisors  run  on  bare-metal  (i.e.,  directly  on  top  of  hardware,  requiring  no  operating 
system). 

This  chapter  discusses  the  VDI  built  in  the  NPS  Cloud  Lab.  It  serves  as  a 

simplistic  example  of  how  a  virtual  desktop  infrastructure  could  be  built  and  integrated 

into  a  shipboard  environment.  The  sections  are  presented  in  an  order  that  corresponds  to 

the  steps  that  were  taken  to  design  and  build  a  VDI  from  beginning  to  end.  The  specific 
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VMware  software  products  used  in  the  Cloud  Lab  are  likewise  introduced  at  the 
appropriate  step  that  would  require  their  installation,  rather  than  introducing  them  all  at 
the  same  time  in  the  beginning  of  this  chapter. 


A.  NPS  CLOUD  LAB  PHYSICAL  INFRASTRUCTURE 


Figure  7  depicts  a  standard  server  setup  without  virtualization.  This  consists  of  the 
server  (the  physical  machine)  with  its  assorted  hardware  (CPU,  HDD,  RAM,  etc.),  an  OS 
installed  on  top  of  the  hardware,  and  applications  installed  on  top  of  the  OS.  A  user 
would  access  data  on  the  server  by  logging  in  to  a  desktop  with  an  available  connection 
to  the  server.  This  is  an  example  of  a  typical  client-server  network  infrastructure,  which  is 
the  current  infrastructure  in  use  onboard  naval  ships. 
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Figure  7.  Server  configuration  without  virtualization  [10] 


As  stated  earlier,  a  ship  has  several  servers.  To  maximize  physical  resources  and 
to  reduce  space,  the  physical  servers  can  be  consolidated  by  using  blade  enclosures  and 
blade  servers. 

1.  Blade  Enclosures 

The  first  step  necessary  in  converting  to  a  virtual  infrastructure  is  to  consolidate 
physical  servers.  Usually,  there  are  several  server  racks  onboard  a  ship.  Each  rack 
contains  either  a  single,  stand-alone  server  or  a  small  number  of  servers.  These  server 
racks  can  be  consolidated  using  blade  enclosures  and  blade  servers,  which  together  are  a 
suitable  solution  for  server  consolidation.  Blade  enclosures  are  stripped  down  versions  of 
rack  mounted  servers  and  are  modular  in  shape.  The  modular  enclosure  (chassis)  reduces 
the  use  of  physical  space  as  well  as  energy  by  housing  multiple  blade  servers.  The 
enclosures  provide  power,  cooling,  networking,  interconnects,  and  management 
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controllers.  In  terms  of  physical  space,  server  consolidation  using  blade  enclosures 
provides  a  much  smaller  footprint  compared  to  the  server  racks  on  ships  today. 

In  building  the  virtual  infrastructure  in  the  NPS  Cloud  Lab  a  Dell  PowerEdge 
MIOOOe  Blade  Enclosure  (see  Figure  8)  was  used.  These  blade  chasses  can  hold  up  to  16 
half-height  or  eight  full-height  blade  servers,  has  space  for  six  power  supplies,  contains 
six  bays  for  I/O  modules,  and  can  accommodate  up  to  256  processor  cores  and  4TB  of 
RAM. 


Figure  8.  Dell  MIOOOe  Blade  Server  Enclosure  [30] 
a.  Blade  Management  Controller 

Integrated  into  the  Dell  MIOOOe  Blade  Enclosure  is  a  Chassis 
Management  Controller  (see  Figure  9).  These  are  small  LCD  devices  situated  on  the  front 
of  the  blade  enclosure.  They  provide  powerful  management  for  the  entire  blade  enclosure 
and  include  real-time  power  management  and  monitoring,  flexible  security,  and  status 
and  inventory  alerts  for  the  chassis  and  any  blade  servers  installed  in  the  chassis. 


Figure  9.  Dell  MIOOOe  Blade  Management  Controller  [30] 
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2. 


Blade  Servers 


Blade  servers  offer  a  robust  and  scalable  enterprise  platfonn  suitable  for  the 
infrastructure  required  of  cloud  computing  and  virtualization.  Small  in  size,  they  are 
easily  added  or  removed  from  a  blade  chassis  as  required.  A  blade  server  contains  all  of 
the  typical  hardware  components  found  in  a  computer,  but  many  of  the  components  have 
been  reduced  in  size  or  removed  altogether  in  order  to  save  space.  However  configured, 
blade  servers  contain  the  necessary  components  required  to  support  the  most  demanding 
computing  and  networking  infrastructures.  They  are  also  equipped  with  internal  USB 
connections  for  embedded  hypervisors,  capable  of  delivering  virtualization  when  using 
virtualization  software  such  as  VMware. 

For  the  VDI  and  cloud  computing  infrastructure  in  this  thesis,  five  Dell 
PowerEdge  M610  Blade  Servers  were  used  (see  Figure  10).  A  M610  Blade  Server  has  a 
memory  capacity  of  up  to  192GB  of  RAM  and  two  CPU  sockets  each  capable  of  six 
cores.  A  M610  Blade  Server  can  effectively  scale  I/O  bandwidth  via  end-to-end  lOGbE, 
important  for  alleviating  bandwidth  constraints. 

A  total  of  five  M610  Blade  Servers  were  installed  in  the  MIOOOe  Blade  Enclosure 
in  the  NPS  Cloud  Lab.  These  servers  were  labeled  AEGIS- 1,  AEGIS-2,  AEGIS-3, 
AEGIS-4,  and  AEGIS-5.  Each  blade  server  was  equipped  with  two  dual  core  Intel  Xeon 
E5540  CPUs  running  at  2.53GHz,  24  GB  of  memory,  and  131GB  of  hard  disk  space. 


Figure  10.  Dell  PowerEdge  M610  Blade  Server  [31] 

3.  Server  Operating  Systems 

Prior  to  building  a  virtual  infrastructure  a  server  operating  system  must  be 
installed  on  one  of  the  physical  servers.  A  server  operating  system  provides  management 
tools  and  other  features  suitable  for  enterprise  level  infrastructures.  Such  features  include 
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the  ability  to  reconfigure  and  update  hardware  or  software  without  restarting  the  server, 
flexible  networking  capabilities,  automation  capabilities,  and  tighter  system  security.  A 
server  operating  system  can  also  serve  as  the  central  management  point  for  all  physical 
servers  installed  in  a  blade  chassis,  and  when  using  virtual  software  it  can  serve  as  the 
central  management  point  for  every  virtual  server  installed  on  the  physical  servers. 

For  the  Cloud  Lab  server  operating  system,  Windows  Server  2008  Revision  2  was 
used.  Windows  Server  2008  R2  is  designed  to  increase  the  reliability  and  flexibility  of 
private  cloud  infrastructures.  Windows  Server  2008  R2  was  installed  on  server  AEGIS- 
1 .  Of  the  entire  infrastructure,  the  server  OS  is  the  only  program  installed  directly  on  top 
of  the  physical  hardware  that  is  not  virtualization  software. 

B.  NPS  CLOUD  LAB  VIRTUAL  INFRASTRUCTURE 

The  physical  servers  and  a  server  OS  completed  the  physical  infrastructure  on 
which  the  virtual  infrastructure  was  to  be  installed.  From  this  point  on,  only  a  few 
virtualization  programs  are  installed  as  programs  on  the  server  OS  and  are  used  solely  for 
the  management  of  the  virtual  infrastructure  on  each  physical  server  (AEGIS- 1  -  AEGIS- 
5).  With  the  physical  infrastructure  in  place,  the  next  step  was  to  install  the  virtual  servers 
that  would  eventually  house  virtual  machines.  A  virtual  server  shares  many  of  the  same 
characteristics  as  a  physical  server,  and  is  tasked  with  managing  the  resources  for  virtual 
machines.  Virtual  servers  allow  for  the  consolidation  of  underutilized  physical  servers, 
leading  to  reductions  in  datacenter  space,  power,  cooling  and  administration 
requirements.  [9]  The  VMware  ESXi  hypervisor  was  the  virtual  server  used  in  the  Cloud 
Lab. 


1.  VMware  ESXi 

On  each  physical  server  is  installed  an  operating  system  or  at  a  minimum  a  kernel 
(also  known  as  a  hypervisor).  A  kernel  shares  functionality  similar  to  an  OS  and  is  the 
bridge  between  the  hardware  level  and  the  software  level.  VMware  developed  a  kernel 
aptly  named  VMkemel,  which  is  embedded  within  their  hypervisor  product  called 
VMware  ESXi,  an  enterprise  level  software  hypervisor.  ESXi  is  a  bare-metal  hypervisor 
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that  runs  on  its  own  kernel;  i.e.,  it  runs  directly  on  a  physical  server’s  hardware.  Figure  1 1 
shows  a  server  configuration  using  ESXi. 


Figure  1 1 .  Server  configuration  with  virtualization  [  1 0] 


ESXi  is  the  first  virtualization  layer  of  the  VDI  and  is  designed  to  specifically 
support  running  multiple  VMs.  ft  does  this  by  abstracting  physical  resources  such  as 
processing,  memory,  and  storage  into  multiple  VMs.  The  hypervisor  footprint  is  small, 
requiring  less  than  32MB  of  the  server’s  physical  HDD,  while  the  entire  ESXi  image  is 
only  750MB.  (As  a  comparison,  Windows  Server  2008  R2  requires  10GB  of  space.)  As  a 
side  benefit,  smaller  footprints  lead  to  a  lower  overall  attack  surface  and  thus  better 
security. 

Access  to  ESXi  is  via  a  Direct  Console  User  Interface  (DCUI),  a  screenshot  of 
which  is  shown  in  Figure  12.  The  DCUI  interface  is  similar  to  that  of  a  BIOS  menu  used 
to  modify  a  computer’s  boot  configuration  and  provides  basic  configuration,  such  as 
setting  the  administrator  password  and  network  configuration. 
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UMuare  ESXi  4.1.0  (UtIKernel  Release  Build  34B481) 


Dell  Inc.  PouerEdge  H610 

2  x  Intel CR)  Xeon(R)  CPU  E5546  »  2.53GHz 
24  GB  Memory 


Download  tools  to  manage  this  host  from: 

http://aegis-s3/ 

http ://19Z . 168 . 100.159/  (STATIC) 


<FZ>  Customize  System  <F12>  Shut  Doum/Restart 

Figure  12.  Screenshot  of  an  ESXi  DCUI  Interface 

An  instance  of  VMware  ESXi  Version  4.1  was  installed  on  each  of  the  remaining 
four  physical  blade  servers  in  the  NPS  Cloud  Lab:  AEGIS-2,  AEGIS-3,  AEGIS-4,  and 
AEGIS -5.  ESXi  was  the  only  program  installed  directly  onto  these  blade  servers  and  the 
DCUI  is  the  only  screen  in  which  a  user  would  interact  with  the  hypervisor.  The  rest  of 
the  virtual  infrastructure  was  constructed  and  managed  from  a  program  called  VMware 
vCenter  Server.  VMware  vCenter  Server  is  explained  next. 

2.  VMware  vCenter  Server 

VMware  vCenter  Server  is  a  simple  and  efficient  way  to  manage  a  virtual 
infrastructure  and  it  provides  a  scalable  and  extensible  platform  that  forms  the  foundation 
for  virtualization  management.  [32]  A  central  point  for  the  configuration  and 
management  of  virtualized  IT  environments,  vCenter  Server  provides  datacenter  services 
such  as  access  control  and  performance  monitoring. 

In  the  NPS  Cloud  Lab  vCenter  Server  was  installed  as  a  program  running  on  the 
Windows  Server  2008  R2  server  OS  on  AEGIS- 1.  From  vCenter  Server,  each  instance  of 
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ESXi  installed  on  the  other  AEGIS  blade  servers  could  be  managed  and  configured. 
Figure  13  shows  the  vCenter  server  hierarchy,  in  which  vCenter  Server  manages  over 
each  instance  of  vSphere  platforms  and  their  virtual  machines. 


VM 

VM 

VM 

VM 

VM 

VM 

VM 

VM 

VM 

VM 

VM ware  vSphere 


VMware  vSphere 


VM  ware  vSphere 


Figure  13.  VMware  vCenter  Server  hierarchy  [32] 

3.  VMware  vSphere 

VMware  vSphere  is  the  VMware  infrastructure  platform  designed  specifically  for 
cloud  computing  when  combined  with  other  VMware  products,  such  as  vCenter  Server 
and  ESXi.  Specifically,  vSphere  “manages  large  collections  of  infrastructure,  such  as 
CPUs,  storage,  and  networking,  as  a  seamless  and  dynamic  operating  environment,  and 
also  manages  the  complexity  of  a  datacenter.”  [10]  As  it  relates  to  the  cloud  computing 
paradigm  of  shared  resources,  vSphere  “virtualizes  and  aggregates  the  underlying 
physical  hardware  resources  across  multiple  systems  and  provides  pools  of  virtual 
resources  to  the  datacenter.”  [10] 

VMware  vSphere  is  not  a  single  program,  rather  it  is  a  software  stack;  i.e.,  it  is  a 
composition  of  virtualization,  management,  and  interface  layers  (illustrated  in  Figure  14). 
Describing  the  layers  as  it  pertains  to  the  setup  in  the  Cloud  Lab,  VMware  ESXi  is  the 
virtualization  layer  and  vCenter  Server  is  the  management  layer,  each  comprising  a  level 
of  the  vSphere  software  stack.  The  interface  layer  is  the  last  layer  to  be  built,  not 
materializing  until  the  last  step  of  the  virtualization  infrastructure  was  completed.  It 


35 


appears  at  the  end  user  segment  in  which  a  user  accesses  a  virtual  machine  via  a  thin 
client  or  a  zero  client. 
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Figure  14.  The  three  layers  of  the  vSphere  software  stack  [10] 

In  addition  to  ESXi  and  vCenter  Server  there  are  several  key  features  of  vSphere 
that  when  leveraged  provide  access  to  crucial  resources  when  needed.  These  features 
together  fonn  one  of  the  core  characteristic  of  the  cloud  computing  paradigm  -  elasticity. 
Each  of  the  following  vSphere  features  were  installed  and  running  on  the  ESXi  servers  in 
the  Cloud  Lab. 


a.  vMotion 

When  this  feature  is  installed  a  powered-on  virtual  machine  can  be 
migrated  from  one  physical  server  to  another  with  zero  downtime.  In  the  event  a  server 
needs  to  be  taken  down  for  maintenance,  any  virtual  machine  in  use  by  a  user  will  be 
seamlessly  transferred  to  another  server.  Continuous  service  availability  and  complete 
transaction  integrity  are  guaranteed.  This  prevents  any  user  from  having  to  wait  to 
continue  working. 
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b.  High  Availability  (HA) 

In  the  event  a  server  fails  the  High  Availability  feature  will  automatically 
restart  any  affected  virtual  machines  on  another  server.  Similar  to  the  vMotion  feature, 
having  HA  provides  users  continuous  access  to  a  virtual  machine. 

c.  Fault  Tolerance 

With  this  feature  enabled  a  secondary  copy  of  a  virtual  machine  is  created 
and  maintained.  Continuous  availability  is  provided  in  the  event  the  original  virtual 
machine  becomes  unavailable.  Fault  tolerance  is  achieved  by  combining  HA  with 
distributed  resource  sharing. 

4.  Hosts,  Clusters,  and  Resource  Pools 

Important  to  allocating  recourses  are  hosts,  clusters,  and  resource  pools,  which  are 
quantities  of  shared  computing,  memory,  and  storage  resources;  Figure  15  graphically 
shows  the  formation  of  hosts,  clusters,  and  resource  pools.  By  aggregating  resources  a 
uniform  set  of  elements  (an  element  being  a  host,  cluster,  or  resource  pool)  are  created  in 
the  virtual  environment.  [33]  The  management  of  these  elements  is  done  via  vSphere  and 
can  be  managed  like  a  shared  utility  and  dynamically  provisioned  out  to  the  virtual 
machines  demanding  resources.  This  sharing  of  resources  is  an  example  of  elasticity  and 
on  demand  resource  sharing,  key  characteristics  of  cloud  computing. 

In  the  Cloud  Lab,  several  hosts  (the  AEGIS  servers)  and  a  multiple  of  clusters  and 
resource  pools  were  used.  Each  of  these  elements  is  described  below,  followed  by  the 
setup  of  the  elements  as  used  in  the  virtual  infrastructure. 

a.  Hosts 

A  host  is  simply  a  computer  that  utilizes  virtual  software  to  run  VMs. 
Hosts  provide  the  resources  such  as  processing  power  and  memory  to  the  VMs.  They  also 
provide  the  VMs  with  access  to  storage  and  networks.  A  host  can  support  hundreds  or 
thousands  of  VMs,  depending  on  the  amount  of  hardware  a  host  has. 


37 


Hosts  can  be  added  to  the  vCenter  Server  for  management.  Five  hosts 
were  added  to  vCenter  Server;  AEGIS- 1  through  AEGIS-5,  which  are  the  servers  for  the 
entire  VDI  in  the  Cloud  Lab. 

b.  Clusters 

Clusters  represent  the  aggregate  computing  power  and  resources  of  several 
hosts  sharing  the  same  network  and  storage  arrays.  Although  a  cluster  draws  resources 
from  several  components,  it  acts  and  can  be  managed  as  a  single  entity.  [10] 

c.  Resource  Pools 

Resources  of  a  host  or  of  a  cluster  can  be  divided  into  resource  pools. 
Resource  pools  are  self-contained  and  can  be  isolated  from  other  resource  pools  on  the 
virtual  infrastructure.  VMs  are  assigned  resources  from  resources  pools.  The  benefit  here 
is  that,  for  example,  one  group  of  VMs  assigned  to  a  set  of  users  whose  work  requires  a 
small  amount  of  resources  can  be  assigned  a  resource  pool  equating  to  their  need, 
whereas  a  different  group  of  users  may  need  a  larger  amount  of  resources  to  complete 
their  work  and  have  their  VMs  assigned  to  a  resource  pool  with  the  requisite  resources 
needed.  Each  resource  pool  can  draw  from  multiple  hosts  (physical  servers),  using  an 
aggregate  amount  of  the  total  resources  available. 

Resource  pools  are  also  dynamic.  When  a  resource  is  not  used  by  a  VM 
that  resource  is  free  to  be  shared  among  other  VMs.  Resource  pools  can  be  nested  and 
organized  hierarchically,  allowing  for  dynamic  reconfiguration  among  any  other  running 
VM.  [33] 


Figure  15.  Hosts,  Clusters,  and  Resource  Pools  [10] 
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5. 


Virtual  Networks 


The  network  portion  of  a  virtual  infrastructure  forms  the  backbone  along  which 
information  transits  and  involves  both  physical  and  virtual  components.  The  virtual 
infrastructure  created  in  the  NPS  Cloud  Lab  had  its  own  virtual  network,  equipped  with 
virtual  switches  and  virtual  ports,  and  was  connected  to  the  physical  NPS  ERN  domain. 
Because  the  VDI  was  connected  to  the  NPS  ERN  domain,  access  to  virtual  machines  was 
possible  from  anywhere  via  a  computer  terminal  with  the  VDI  client  software  installed. 

A  virtual  network  is  very  similar  to  a  physical  network.  A  physical  network 
consists  of  a  number  of  physical  computers  connected  via  a  switch.  Switches  manage 
traffic  between  computers  and  form  the  core  of  a  physical  network.  Switches  have  several 
ports,  which  connect  to  a  computer  or  another  switch.  Ports  can  be  configured  to  match 
the  needs  of  a  computer  connected  to  it. 

Whereas  a  physical  network  has  several  computers  connected  to  each  other  via  a 
switch,  a  virtual  network  has  several  virtual  machines  running  on  a  single  physical 
computer  and  is  managed  by  a  virtual  switch,  which  is  created  during  the  initial 
construction  of  a  virtual  infrastructure.  VMware  vSphere  contains  its  own  switches, 
called  vSphere  Distributed  Switches. 

a.  vSphere  Distributed  Switch 

A  vSphere  Distributed  Switch  (VDS)  is  similar  to  a  physical  network 
switch  in  that  it  connects  network  segments  within  Local  Area  Networks  (LANs).  The 
virtual  switch  detects  the  virtual  machines  connected  to  the  switches’  virtual  ports  and 
one  VDS  can  span  multiple  ESXi  hosts.  The  benefits  include  a  reduction  of  network 
maintenance  activities  and  an  increase  in  network  capacity  and  the  resulting  increase  in 
efficiency  enables  VMs  to  maintain  consistent  network  configuration  as  they  move 
among  hosts.  [33] 

Each  virtual  port  on  a  VDS  can  be  grouped  together,  forming  a  port  group. 
These  groups  specify  configuration  options,  including  bandwidth  limitations,  and  define 
how  connections  are  made  through  a  VDS  to  a  network.  The  virtual  network  connects  to 

a  physical  network  by  connecting  a  VDS  to  a  physical  network  using  uplink  adapters. 
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6.  Storage 

The  storage  setup  used  for  the  virtual  infrastructure  in  the  Cloud  Lab  included  the 
hard  disk  drives  on  the  AEGIS  servers  and  the  hard  disk  drives  that  comprised  the 
Storage  Area  Network  (SAN).  Storage  available  on  the  AEGIS  servers  was  reserved 
specifically  for  applications  installed  directly  on  the  server  (such  as  ESXi).  Storage  for 
users  of  virtual  machines  resided  on  the  SAN.  A  SAN  is  a  dedicated  network  providing 
access  to  storage  devices  accessible  by  a  server.  Suitable  for  enterprise  networks,  a  SAN 
can  consolidate  storage  space  in  much  the  same  way  blade  servers  consolidate  servers. 
For  example,  a  desktop  computer  has  its  own  internal  HDD.  When  zero  clients  replace 
desktop  computers,  which  do  not  have  internal  HDDs,  all  storage  resides  on  a  SAN.  A 
SAN  is  one  physical  unit  containing  multiple  hard  drives,  much  like  how  a  blade 
enclosure  contains  multiple  blade  servers. 

The  SAN  used  in  the  NPS  Cloud  Lab  contained  16  SCSI  HDDs.  Each  HDD  had 
500GB  of  storage  space.  All  16  HDDs  combined  equaled  8TB  of  storage.  The  SAN  was 
partitioned  into  three  separate  resource  pools,  with  two  resource  pools  each  having  2TB 
of  storage  and  the  third  resource  pool  having  1.5  TB. 

7.  VMware  View 

VMware  View  was  the  last  virtual  software  program  to  be  installed  in  the  VDI. 
There  are  two  versions  of  View,  View  Manager  and  View  Client.  View  Manager  is  a 
universal  client  solution  that  lets  an  administrator  manage  every  aspect  of  a  deployed 
virtual  machine.  Operating  systems,  hardware,  applications,  and  independent  users  can  be 
managed  from  anywhere,  regardless  of  where  a  user  accesses  a  virtual  machine.  View 
Client  is  the  end  user  segment  in  which  a  user  accesses  a  virtual  machine  from  a  pool  of 
available  virtual  machines,  and  is  discussed  in  the  next  section  of  this  chapter. 

Of  all  the  VMware  applications  used  in  the  NPS  Cloud  Lab,  VMware  View 
essentially  offers  a  unique  cloud  computing  service:  delivery  of  user  desktops  as  a 
service.  View  accomplishes  this  by  delivering  desktops  and  applications  securely  to 
remote  clients  anywhere,  resulting  in  a  highly  available,  agile  cloud  service. 
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View  has  a  powerful  tool  that  makes  the  creation  of  virtual  machines  easy  -  View 
Composer.  View  Composer  is  designed  specifically  for  making  virtual  machines  in  large- 
scale  environments.  In  View  Composer,  a  customizable  template  can  be  created  and 
tailored  to  the  needs  of  an  enterprise.  Once  this  template  is  created  it  becomes  a  parent 
(standard)  virtual  machine  image.  This  template  then  allows  for  the  rapid  and  automatic 
replication  of  itself  to  create  multiple  virtual  machines  (see  Figure  16).  By  using  linked 
clones,  updates  need  only  be  applied  to  the  parent  image.  All  other  virtual  machines  that 
are  an  image  of  the  parent  image  can  then  be  updated  in  a  streamlined  manner. 


Linked 

Clones 


Figure  16.  Parent  image  with  linked  clones  [10] 

8.  Virtual  Machines  and  the  End  User  Interface 

The  last  step  in  building  the  virtual  desktop  infrastructure  was  to  create  VMs 
using  View  Manager  and  to  test  them  via  an  end  user  interface.  To  create  the  VMs  a 
template  was  first  made  tailored  to  the  needs  of  the  audience  that  would  be  using  the 
VMs  on  the  NPS  campus  (mainly  NPS  students). 

With  the  template  constructed  the  replication  process  was  simple  to  execute.  After 
the  desired  number  of  VMs  was  entered  (50,  in  this  case),  View  automatically  created  the 
VMs  based  off  the  customized  template.  Each  VM  was  linked  to  an  account  in  the  Active 
Directory,  which  allowed  a  user  with  an  NPS  account  to  log-in  to  a  terminal  with  the 
VMware  View  Client  installed  and  access  a  VM.  View  Client  is  the  end  user’s  gateway 
to  a  virtual  machine  and  is  the  software  portion  of  the  interface  layer  of  the  vSphere 
software  stack. 
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The  hardware  portion  of  the  interface  layer  can  be  any  computer  client  device 
such  as  a  laptop,  a  desktop  computer,  a  mobile  device  (smart  phones),  or  a  thin  client  or 
zero  client.  In  the  Cloud  Lab  PCoIP  zero  client  devices,  manufactured  by  Wyse,  were 
used.  The  virtual  machines  were  delivered  using  the  PCoIP  protocol  and  presented  to  the 
end  user  on  a  thin  client  device  or  a  zero  client  device.  All  virtual  desktops  were  centrally 
located  and  managed  in  the  data  center  by  vSphere  and  View  Manager,  while  the  end 
user  accessed  a  virtual  machine  through  View  Client  on  the  user’s  client  device. 

The  VDI  was  tested  using  Wyse  P20  zero  client  devices  (see  Figure  17).  Wyse  is 
a  global  leader  in  cloud  client  computing  devices.  The  P20  is  a  small  zero  client  designed 
to  be  used  with  VMware  View  and  contains  very  little  hardware;  128MB  RAM,  a  small 
processor,  video  card,  and  a  NIC.  Several  audio,  video,  USB,  and  network  ports  are 
integrated  into  the  P20,  offering  all  the  connections  necessary  for  a  mouse,  keyboard,  and 
monitor,  as  well  as  the  connection  to  the  host  servers  that  are  home  to  the  VMs.  Overall, 
the  P20  is  compact,  energy  efficient,  and  “delivers  a  rich  user  experience  while  resolving 
the  challenges  of  provisioning,  managing,  maintaining  and  securing  enterprise  desktops.” 
[34] 


Figure  17.  A  Wyse  P20  zero  client  device  [34] 

The  VDI  was  successfully  accessed,  not  only  from  the  Wyse  P20  zero  client,  but 
also  from  standard  desktop  computers  and  laptop  computers,  located  on  and  off  the  NPS 
campus.  The  PCoIP  protocol  was  implemented  successfully;  VMs  were  delivered  over 
the  internet  to  the  client  devices  and  ThinApps  and  standard  applications  streamed 

uninterrupted  from  the  host  servers  in  the  datacenter  to  the  VMs.  Figure  18  is  an 

42 


illustration  of  the  VDI’s  physical  connections  between  the  Blade  Chassis  and  Blade 
Servers,  the  Zero  Clients,  and  the  ERN  and  the  Internet.  Figure  19  depicts  the  overall 
VDI,  including  each  AEGIS  server  virtual  layer  composition,  and  the  physical  and  virtual 
connections  between  the  AEGIS  servers  and  the  View  Manager  Workstation,  View 
Client  Devices  (zero  clients),  the  ERN,  and  the  Internet. 


Figure  18.  NPS  Cloud  Lab  Blade  Chassis  and  VDI  physical  connections 
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Figure  19.  NPS  Cloud  Lab  VDI  physical  and  virtual  connections 


C.  SHIPBOARD  VIRTUAL  DESKTOP  INFRASTRUCTURES 

Based  on  the  VDI  created  in  the  Cloud  Lab  it  is  possible  to  conceptually  scale  it 
to  construct  what  a  VDI  would  look  like  onboard  a  ship.  The  major  differences  lie  in  the 
size  of  the  infrastructure,  the  hardware  requirements,  and  the  level  of  application  the  VDI 
would  be  subjected  to.  The  VDI  proposed  here  is  not  for  tactical  applications,  such  as  the 
AEGIS  weapons  system  on  an  Arleigh-Burke  class  destroyer  or  on  a  Ticonderoga  class 
cruiser.  Rather,  it  is  designed  for  use  with  non-tactical  applications,  such  as  standard 
email  programs  and  servers,  Microsoft  Office  products,  administrative  programs,  and 
applications  like  those  delivered  by  NIAPS  (NIAPS  -  or  Navy  Information  Application 
Product  Suite  -  delivers  “maintenance,  logistics,  administrative,  training  and 
management  applications  to  users  at  sea.”  [35])  Tactical  applications  could  also  be 
considered  conceptually  as  another  implementation  of  the  NPS  Cloud  Lab  VDI. 

The  technology  standards  required  to  run  the  VDI  as  built  in  the  Cloud  Lab  are 
not  different  from  those  currently  found  on  shipboard  network  infrastructures.  The  only 
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exception  is  the  relatively  new  logical  internet  protocol  PCoIP,  which  is  integrated  into 
VMware  software  and  requires  nothing  more  than  using  zero  client  devices  capable  of 
utilizing  the  protocol  (such  as  the  Wyse  P20  zero  client  used  in  the  Cloud  Lab). 

The  physical  requirements  necessary  to  run  a  VDI  on  a  ship  would  be  relative  to 
the  size  of  the  ship  and  the  number  of  users  onboard.  The  requisite  amount  of  CPUs, 
HDDs,  RAM,  and  other  components  for  the  host  servers  on  which  a  VDI  would  reside 
would  have  to  be  determined  prior  to  consolidation  of  the  ship’s  existing  servers.  One 
method  would  be  to  total  the  hardware  of  the  rack-mounted  servers  onboard  the  ship  and 
use  the  resulting  calculated  figures  as  the  minimum  amount  of  hardware  necessary  to  run 
the  ship’s  networking  infrastructure  using  blade  servers.  The  physical  resources  for  the 
VDI  would  then  be  added  by  expanding  the  number  of  blade  servers  after  the  ship’s 
servers  have  been  consolidated.  Figure  20  illustrates  the  consolidation  of  physical  servers 
into  one  physical  server,  with  an  instance  of  the  ESXi  hypervisor  and  virtual  machines 
installed. 
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Figure  20.  Physical  server  consolidation  [10] 


Requirements  for  individual  virtual  machines  depend  on  the  number  of  users.  A 
ship  with  300  personnel  would  require  300  VMs.  However,  a  spare  VM  should  be 
available  to  every  user  in  the  event  a  spare  VM  is  needed.  Therefore  600  VMs  is  a  fair 
number  of  VMs  for  a  ship  with  300  personnel  on  board.  To  adequately  determine  the 
resources  needed  for  600  virtual  machines  a  test  VM  should  be  created  first.  This  test  VM 
should  have  installed  on  it  all  of  the  applications  that  would  be  used  onboard  the  ship. 
Stress  tests  should  then  be  conducted  to  determine  the  physical  resources  necessary  for 
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the  VM  to  operate  efficiently  and  satisfy  user  needs.  After  the  test  VM  has  met  these 
conditions  the  physical  resources  that  were  required  to  sufficiently  run  the  VM  can  be 
multiplied  by  the  number  of  desired  VMs  to  determine  the  overall  requirement  of 
physical  resources  to  run  the  VDI. 

For  example,  if  3GB  of  RAM  and  300Hz  of  processing  power  was  the  minimum 
required  to  successfully  run  the  test  VM,  then  600  x  3GB  of  RAM  and  600  x  300Hz  of 
processing  power  is  necessary  to  support  600  VMs  (or  1,800GB  (1.8TB)  of  RAM  and 
180,000Hz  of  processing  power  -  the  equivalent  of  60  3GHz  CPUs).  A  small  number  of 
blade  servers  are  more  than  capable  of  handling  this  amount  of  physical  resources. 

Storage  requirements  depend  on  the  combined  size  of  the  applications  plus  the 
amount  of  storage  administrators  want  to  allocate  to  a  user.  The  size  of  a  SAN  for  600 
users  can  be  calculated  in  the  same  fashion  as  the  previous  example  to  detennine  RAM 
and  processing  power.  If,  for  example,  10GB  of  storage  were  to  be  allocated  to  each  user 
and  there  are  300  users,  then  3,000GB  (3TB)  would  be  a  sufficient  amount  of  storage. 
For  comparison,  the  SAN  in  the  Cloud  Lab  had  the  equivalent  of  5,500GB  (5.5TB)  of 
storage. 

It  is  important  to  remember  that  one  of  the  prime  reasons  for  moving  to  a  cloud 
architecture  with  a  virtualized  infrastructure  is  to  capitalize  on  elasticity.  While  it  is 
unlikely  100%  of  resources  will  be  used  at  any  given  time,  additional  resources  to  the 
100%  must  be  available  if  the  need  arises.  A  VDI  integrated  into  a  shipboard  network 
infrastructure  designed  for  300  users  but  with  the  capacity  to  handle  600  users  should  be 
able  to  accommodate  a  sudden  spike  in  demand  for  resources.  However,  ships  are  not 
equipped  with  a  number  of  workstations  equivalent  to  the  number  of  personnel  on  board. 
Though  a  ship  such  as  an  Arleigh-Burke  class  destroyer  may  have  300  personnel,  there 
are  approximately  250  workstations  throughout  the  ship.  In  this  case,  it  is  only  possible 
for  250  of  the  600  VMs  to  be  used  at  any  given  time,  and  even  then  that  is  only  if  every 
workstation  was  being  used,  which  is  unlikely. 

The  replacement  of  desktop  computers  with  zero  clients  like  the  Wyse  P20  would 
account  for  much  of  the  creation  of  elastic  resources.  Desktop  computers  contain  their 
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own  hardware  and  therefore  their  own  resources.  Those  resources  are  rarely,  if  ever,  fully 
utilized.  A  VM,  on  the  other  hand,  pulls  its  resources  from  resource  pools  on  the  host 
servers  and  only  uses  the  resources  necessary  to  run  the  VM  itself  and  any  applications 
installed  on  it.  Any  remaining  unused  resources  in  the  resource  pools  are  available  for 
other  VMs  to  use.  The  resources  on  desktop  computers  are  wasted  because  it  cannot  be 
used  by  another  computer  if  there  is  a  demand;  i.e.,  desktop  computers  are  not  scalable. 
In  a  VDI  resources  are  scalable;  they  are  available  to  other  VMs  when  in  demand.  If 
demand  for  resources  is  low  enough  to  meet  a  set  threshold  then  the  host  server(s)  can 
automatically  shutdown  to  preserve  power  consumption. 

Based  on  the  examples  given  in  this  section  and  the  VDI  built  in  the  NPS  Cloud 
Lab  as  discussed  in  this  chapter,  a  model  shipboard  VDI  requires  a  small  number  of 
phases  to  build  and  integrate  into  a  shipboard  network  infrastructure.  There  are  primarily 
three  phases.  The  first  is  to  consolidate  servers  currently  existing  onboard  a  ship  and  to 
add  the  requisite  number  of  servers  on  which  a  virtual  infrastructure  would  reside.  In  this 
first  phase,  analysis  of  the  requisite  number  of  servers  must  be  done.  Blade  chasses  and 
blade  servers  are  suitable  solutions  for  server  consolidation.  The  second  step  is  to 
construct  a  VDI  and  install  on  it  the  applications  to  be  used  in  the  enterprise.  Using  the 
VDI  powered  by  VMware,  as  built  in  the  Cloud  Lab,  offers  a  simple  approach. 
VMware’s  software  products  are  designed  specifically  for  enterprises  seeking  a  cloud 
computing  infrastructure  with  virtualization  at  its  core.  The  last  step  is  to  replace  a  ship’s 
desktop  computers  with  zero  clients.  Zero  clients  reduce  the  footprint  of  physical  space 
throughout  a  ship  and  are  easily  managed. 

A  VDI  designed  to  meet  user  needs  and  properly  integrated  into  a  ship’s  network 
infrastructure  offers  a  cloud  computing  enterprise  network  foundation  that  is  agile, 
elastic,  and  scalable.  Resources  are  only  utilized  when  in  demand  and  are  preserved  when 
not  in  demand.  Desktops  are  streamed  to  users  over  the  shipboard  network,  delivering  a 
unique  cloud  service  -  desktop-as-a-service.  Management  is  centralized  in  one  server  that 
presides  over  the  entire  VDI.  Conducting  maintenance  on  physical  servers  and  applying 
patches  and  updates  to  the  VDI  can  be  done  without  affecting  the  availability  of  VMs  to 
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users.  In  sum,  a  VDI  incorporating  these  beneficial  characteristics  is  a  suitable  foundation 
for  a  shipboard  level  cloud  computing  architecture. 

Figure  21  shows  a  screenshot  of  the  vSphere  Client,  which  provides  status  of  the 
overall  condition  of  the  VDI,  including  the  availability  of  resources  and  the  state  of  the 
virtual  machines  (powered  on/off).  Note  the  amount  of  processing  power  and  RAM 
available  in  the  resource  pool  for  the  50  virtual  machines  residing  on  the  AEGIS  servers. 


Figure  2 1 .  Screenshot  of  the  vSphere  Client  manager  screen 
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IV.  CLOUD  COMPUTING  CONCEPT  OF  OPERATIONS 


The  previous  chapter  focused  on  virtual  desktop  infrastructures  as  the  foundation 
of  a  cloud  computing  architecture  on  a  shipboard  level.  A  VDI  was  built  in  the  Cloud  Lab 
at  NPS  to  give  insight  into  what  a  virtual  infrastructure  looks  like,  the  steps  to  design  and 
implement  it,  how  it  operates,  and  the  requirements  to  operate  it.  This  chapter  looks  at  the 
implementation  of  cloud  computing  in  afloat  multi-ship  environments.  For  the  physical 
cloud  computing  infrastructure  in  a  multi-ship  environment  it  is  assumed  that  each  ship 
has  its  own  private  cloud,  outfitted  with  the  virtual  desktop  infrastructure  designed  in  the 
previous  chapter. 

An  underlying  yet  important  benefit  of  cloud  infrastructures  in  multi-ship 
environments  is  the  potential  minimization  of  satellite  communications  use  by  ships  in  a 
strike  group,  which  may  result  in  a  reduction  in  bandwidth  consumption.  Though  the 
push  and  pull  of  data  between  a  strike  group  and  shore  facilities  via  satellites  is  for  the 
most  part  unavoidable  (especially  when  operating  in  distant  blue  waters),  the  ability  to 
link  each  ship’s  cloud  with  every  other  ship  in  a  strike  group  offers  an  alternative  to 
reliance  on  satellites.  Mobility  of  cloud  services  and  the  mobility  of  clouds  themselves 
(i.e.,  the  ships)  is  naturally  key  to  the  afloat  cloud  infrastructure.  To  support  this  “cloud 
on  the  move”1  concept,  assets  linking  shipboard  clouds  in  the  afloat  environment  will  be 
a  crucial  role  if  data  is  to  be  shared  between  clouds.  The  next  section  proposes  several 
methods  of  linking  clouds. 

A.  LINKING  CLOUDS 

Numerous  possible  configurations  for  an  afloat  cloud  infrastructure  in  multi-ship 
environments  exist  given  the  various  assets  and  communication  methods  within  the 
DoD’s  inventory.  This  section  identifies  and  discusses  configurations  using  assets 
capable  of  acting  as  links  for  clouds  afloat,  such  as  lighter-than-air  (LTA)  ships,  fixed 


1  “Cloud  on  the  move”  was  coined  by  Albert  Barreto  while  conducting  research  for  this  thesis  in  the  NPS 
Cloud  Lab.  Credit  is  given  to  him  here  for  the  phrase. 
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wing  aircraft,  IP  routable  satellites,  and  Worldwide  Interoperability  for  Microwave 
Access  (WiMAX)  communications. 

The  current  typical  strike  group  composition  consists  of  an  aircraft  carrier,  an 
oiler,  a  submarine,  and  a  combination  of  a  small  number  of  surface  combatants  that  can 
include  cruisers,  destroyers,  and  frigates.  In  a  cloud  infrastructure  the  ship  with  the  best 
communications  equipment  and  technology  would  serve  as  the  “hub”  of  the  cloud 
network,  which  in  the  case  of  a  strike  group  the  role  would  be  fulfilled  by  the  aircraft 
carrier.  Each  additional  ship  in  the  strike  group  then  becomes  a  “node”  or  “edge  cloud.” 
Though  each  ship  has  its  own  unique  cloud,  when  linked  together  they  form  one 
composite  cloud  capable  of  sharing  data. 

When  ships  are  within  Line-of-Sight  (LOS)  data  can  be  shared  via  UHF  LOS  or 
even  HF,  but  these  communication  methods  have  very  low  data  rates  and  would  not  meet 
the  large  bandwidth  requirements  to  exchange  data  from  cloud  to  cloud.  When  ships 
operate  beyond  LOS  data  is  shared  over  satellite  communications  (SATCOM).  In  order 
to  reduce  satellite  saturation  and  free  bandwidth  for  other  uses,  alternatives  to  satellites 
are  needed. 

Figure  22  depicts  a  basic  example  of  individual  shipboard  edge  clouds  linking  to  a 
hub.  In  this  instance,  the  hub  is  the  uplink  and  downlink  of  data  from  satellites.  The  hub 
receives  data  both  from  shore  facilities  via  satellite  and  from  each  edge  cloud  via 
communications  other  than  satellite.  Upon  receiving  data,  the  hub  processes  and 
disseminates  the  data  to  the  rest  of  the  strike  group,  similar  to  a  satellite  broadcast.  In  a 
way,  the  hub  conducts  the  push  and  the  pull  of  data  for  the  strike  group.  The  benefit  here 
would  be  that  ships  other  than  the  hub  in  the  strike  group  do  not  have  to  utilize  a  satellite, 
therefore  freeing  satellite  bandwidth  that  would  have  been  consumed  by  each  ship.  The 
infrastructure  just  described  is  one  of  many  possible  infrastructures.  Listed  below  are 
technologies  that  may  be  suitable  for  linking  clouds  in  a  multi-ship  environment. 
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Figure  22.  Multi-ship  Afloat  Cloud  Infrastructure 

1.  LTA  Ships 

Lighter-Than-Air  ships  are  lightweight,  inexpensive,  helium  filled  dirigibles. 
They  have  been  in  use  in  the  US  military  for  decades,  but  only  recently  has  a  case  been 
made  to  reintroduce  them  into  the  fleet  as  a  useful  asset  in  maritime  operations.  LTA 
ships  are  capable  of  heavy  strategic  lift,  require  very  little  manning,  have  lengthy  on 
station  durations  (up  to  30  days),  and  most  important  in  today’s  military  they  are 
considerably  cheap  relative  to  other  ship  programs  of  record.  [36] 

More  relevant  to  this  thesis  is  the  potential  LTA  ships  have  in  cloud  computing 
infrastructures  in  afloat  environments.  An  LTA  ship,  when  outfitted  with  the  requisite 
equipment,  can  act  as  a  node  in  a  cloud  network,  as  illustrated  in  Figure  23.  As  a  node,  an 
LTA  ship  can  serve  as  a  forwarding  station,  linking  assets  in  a  strike  group  when  they  are 
beyond  LOS;  though,  the  LTA  ship  itself  would  have  to  be  within  LOS  of  the  ships. 
Operating  at  high-speeds  (70-90  knots)  several  thousands  of  feet  in  the  air,  able  to 
withstand  unfavorable  weather  conditions,  and  a  low  level  of  vulnerability  to  enemy  fire, 
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LTA  ships  are  a  versatile  solution  to  extending  a  cloud  infrastructure  and  linking  nodes 
within  a  cloud  network  over  great  distances.  The  same  technologies  found  on  satellites 
can  also  be  installed  on  an  LTA  ship,  able  to  accommodate  the  physical  small  size  of 
satellite  systems.  Additionally,  LTA  ships  can  “readily  accommodate  common  C4I 
architecture  for  maximum  interoperability,”  “enhance  data  sharing  across  multiple 
applications  and  domains,”  and  can  be  “scaled/tailored  to  suit  lift,  endurance,  sensor  and 
communication  requirements.”  [36] 


LTA  Ship 


Figure  23.  LTA  Ship  acting  as  a  data  relay 


2.  Fixed-wing  Aircraft 

The  use  of  fixed-winged  aircraft,  particularly  unmanned  aerial  vehicles,  is  a 
possible  solution  to  extending  edge  clouds  beyond  LOS.  These  systems  have  capabilities 
similar  to  LTA  ships  and  have  very  high  data  rates,  but  their  on-station  duration  is 
relatively  short  given  they  must  refuel  often.  A  current  POR  likely  capable  of  meeting  the 
requirements  to  link  shipboard  clouds  to  a  hub  is  the  Broad  Area  Maritime  Surveillance 
Unmanned  Aircraft  System  (BAMS).  BAMS  provides  “persistent  maritime  Intelligence, 
Surveillance,  and  Reconnaissance  (ISR)  data  collection  and  dissemination  capability,” 
and  it  functions  as  a  communications  relay.  [37] 

BAMS  and  other  maritime  aircraft  such  as  the  P-3  Orion  or  P-8  Poseidon  can  act 
as  a  communications  relay  of  data  from  cloud  to  cloud.  Unlike  LTA  ships,  these  data 
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relays  would  likely  be  used  in  high-intensity  situations  where  LTA  ships  would  not  be 
suitable  for  use.  Except  for  in  those  cases,  the  role  of  a  data  relay  would  be  a  secondary 
mission  for  fixed-wing  aircraft  unless  the  aircraft  is  designed  specifically  to  link 
distributed  cloud  nodes  at  sea. 

3.  IP  Routable  Satellites 

Though  one  of  the  primary  reasons  for  a  mobile  cloud  infrastructure  is  to  operate 
in  an  environment  devoid  of  satellites,  IP  routable  satellite  systems  are  a  unique 
alternative  to  other  satellites  because  they  use  the  IP  protocol.  Many  cloud  services  are 
web  based  services  and  are  already  designed  to  function  using  the  IP  protocol  suite.  Two 
recent  and  emerging  technologies  in  this  category  are  the  Broadband  Global  Area 
Network  system  and  the  Internet  Routing  in  Space  satellite  system  by  Cisco  Satellite 
Solutions. 


a.  Broadband  Global  Area  Network 

The  Broadband  Global  Area  Network,  or  BGAN,  is  a  global  satellite 
Internet  network  system.  The  system  utilizes  the  Internet  Protocol  suite  to  deliver  internet 
services  to  end  users.  Typical  applications  include  email,  internet  and  intranet  access, 
secure  VPN,  VoIP,  file  transfer,  and  remote  surveillance,  among  others.  [38]  BGAN  is  a 
viable  and  suitable  solution  to  linking  nodes  in  an  afloat  cloud  infrastructure  for  several 
reasons. 

First,  BGAN  terminals  are  portable  devices  small  enough  to  fit  inside  a 
backpack.  Compact  terminal  size  is  a  plus  when  considering  network  footprint  reduction, 
especially  when  they  are  to  be  installed  onboard  ships  or  aircraft.  Second,  the  IP 
streaming  rates  range  from  32kbps  to  492kbps.  Although  these  speeds  are  less  than 
desirable,  a  BGAN  satellite  would  suffice  given  the  only  connection  they  are  providing  is 
a  relay  of  data  between  cloud  nodes  (ships).  Third,  BGAN  is  delivered  by  satellites  that 
are  part  of  the  INMARSAT  (International  Maritime  Satellite  Organization)  satellite 
system,  which  has  been  in  use  by  the  US  military  for  decades.  Lastly,  BGAN  benefits 
from  the  security  built  into  INMARSAT,  a  satellite  system  that  has  proven  its  security 
over  time. 
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b.  Cisco  Internet  Routing  in  Space 

Cisco's  Internet  Routing  in  Space  (IRIS)  systems,  like  BGAN,  offers 
Internet  routing  via  satellites.  Cisco  claims  their  satellite  solutions  deliver  “scalable 
service  offerings  for  enterprise  networking,  broadband  and  backhaul  applications.”  [39] 
These  satellite  solutions  may  also  be  utilized  as  a  data  relay  station  between  mobile  cloud 
nodes  (ships)  in  a  strike  group.  A  recent  Joint  Capabilities  Technology  Demonstration 
(JCTD)  of  the  Cisco  IRIS  program  was  successful  in  providing  end-to-end  security  and 
connectivity.  [40] 


IRIS  runs  on  the  Intelsat  satellite  system.  Capable  of  delivering  up  to 
50Mbps  [41],  these  secure  satellites  are  powerful  and  may  adequately  fulfill  the  role  of  a 
data  relay  in  an  afloat  cloud  infrastructure.  Figure  24  provides  an  illustration  of  the  IRIS 
system  servicing  various  afloat  and  ashore  end-users. 


Figure  24.  Illustration  of  Cicso’s  Internet  Routing  in  Space  servicing  remote  users  [40] 


4.  Worldwide  Interoperability  for  Microwave  Access 

Possibly  the  best  method  of  transferring  data  between  nodes  in  an  afloat  cloud 
infrastructure  is  via  WiMAX  (Worldwide  Interoperability  for  Microwave  Access). 
WiMAX  is  part  of  the  4G  (Fourth  Generation)  mobile  communications  standards, 
capable  of  providing  ultra-broadband  Internet  access  over  wireless  communications  at 
speeds  of  up  to  70Mbps.  [42]  Of  particular  importance  to  afloat  cloud  infrastructures  is 
the  distance  WiMAX  offers,  up  to  30  miles. 
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For  the  relay  of  data  to  work  between  nodes  in  a  strike  group  WiMAX  antennas 
or  towers  would  have  to  be  installed  on  each  ship  (see  Figure  25).  For  example,  one 
WiMAX  tower  (capable  of  providing  coverage  to  areas  as  large  as  3,000  square  miles 
[43])  would  be  installed  on  the  hub,  and  smaller  receive/transmit  antennas  on  each  ship. 
An  example  of  this  configuration  is  depicted  in  Figure  26. 


Figure  25.  A  WiMAX  Tower  (left)  and  a  WiMAX  Antenna  (right)  [43],  [44] 


Figure  26.  Possible  WiMAX  infrastructure 


A  message  released  in  April,  2012  titled  “Naval  Air  Systems  Command  plans  4G 
cell  service  aboard  ships”  is  a  promising  step  towards  the  integration  of  WiMAX  in  afloat 
network  architectures.  [45]  The  Navy  plans  on  testing  4G  LTE  (Long-Term  Evolution) 
broadband  communications  capabilities  in  2013  on  three  ships.  Key  features  include  an 
initial  throughput  of  8  to  15  Mbps  with  an  eventual  throughput  of  lGbps  as  technology 
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matures,  a  range  of  30  miles,  and  most  relevant  to  an  afloat  cloud  architecture  the  4G 
systems  “will  support  the  exchange  of  a  variety  of  broadband  data  while  ships  are 
underway,  freeing  up  expensive  and  limited  satellite  bandwidth.”  [45] 

Whether  it  is  the  use  of  LTA  ships  or  WiMAX,  ships  in  an  afloat  cloud  network 
should  use  technologies  other  than  satellites  to  link  the  cloud  infrastructure  between 
ships.  This  should  be  done  primarily  for  two  reasons;  (1)  the  latency  and  bandwidth 
characteristics  found  in  technologies  such  as  LTA  ships  or  WiMAX  are  superior  to  those 
found  in  satellites,  and  (2)  current  and  future  warfare  doctrine  assumes  the  U.S.  military 
will  be  fighting  in  a  degraded  or  denied  satellite  environment. 

Each  ship,  equipped  with  its  own  private  cloud,  will  need  a  connection  that  is  fast 
(low  latency)  and  has  a  bandwidth  large  enough  that  is  capable  of  delivering  large 
amounts  of  data  between  clouds.  The  technologies  listed  above  are  potential  solutions  to 
linking  clouds,  allowing  for  data  to  be  shared  between  clouds.  Just  as  important  as  how 
data  is  shared  is  where  data  is  stored,  discussed  in  the  next  section. 

B.  CLOUD  DATA  STORAGE 

Where  data  is  stored  will  dictate  what  an  afloat  cloud  infrastructure  looks  like 
more  so  than  the  communications  method  used.  The  method  of  communication  simply 
links  clouds  and  delivers  the  data  from  its  storage  location.  Where  and  how  data  is  stored 
depends  on  several  factors,  such  as  the  technology  used,  the  size  of  the  datacenter,  the 
volume  of  data,  the  sensors  collecting  data,  etc.  One  of  the  five  essential  characteristics  of 
cloud  computing  is  on-demand  self-service,  part  of  which  includes  provisioning  network 
storage.  Using  a  VDI  like  the  one  built  in  Chapter  III  provides  each  cloud  its  own  data 
center  capable  of  provisioning  resources,  including  storage.  This  is  acceptable  for  each 
ship  individually,  but  information  that  needs  to  be  shared  among  a  strike  group  will  need 
to  be  stored  in  a  location  accessible  by  all  clouds. 

The  PEO-C4I  Framework  for  Cloud  Computing  at  the  Tactical  Edge  report 
contains  the  DON  Data/Infonnation  Life  Cycle,  which  defines  the  process  of  the  entire 
life  cycle  of  data,  from  identifying  the  need  for  data  to  data  disposal.  [27]  This  detailed 
data  process  can  be  used  to  help  detennine  where  data  should  reside  in  an  afloat  cloud 
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computing  multi-ship  environment.  Table  1  lists  key  steps  in  the  process,  providing 
insight  as  to  the  requirements  of  where  data  may  be  stored.2 


Life  Cycle  Phase 

Definition 

Identify  Need 

Identify  the  potential  contained s)  for  the  specific 
data/information  need  for  storage,  processing,  transport,  and 
management 

Identify  Architecture 

Identify  options  for  data  cache/staging/storage  location(s) 

Task  Collection/ 
Creation 

Identify  the  application(s),  system(s),  service(s),  and/or 
network(s)  that  will  use,  process,  store,  and/or  transport  the 
created  data/infonnation 

Collect/Create 

Detennine  the  accessibility  requirement  for  the  data/information 
asset(s) 

Disseminate 

Transmit,  publish-and-subscribe,  or  broadcast  data/information 
assets  to  applicable  customers  (applications,  systems,  services, 
or  personnel) 

Store 

Store  the  data/infonnation  asset 

Dispose 

Destroy  data/infonnation  asset(s)  that  are  no  longer  needed  to 
support  the  established  requirement  or  have  exceeded  their  time 
period  for  retention 

Table  1.  PEO-C4I  select  steps  of  the  Infonnation  Life  Cycle  Process  [27] 


Based  on  the  definitions  of  the  life  cycle  phases  listed  above  there  are  two  phases 
most  responsible  for  dictating  where  data  storage  should  take  place.  The  first  is  Identify 
Need.  Where  data  will  be  stored  will  depend  on  which  edge  cloud  actually  needs  the 
identified  data.  The  second  is  Task  Collection/Creation.  Several  factors  can  be 
incorporated  into  this  phase.  For  example,  if  the  information  needed  is  intelligence  based 
then  the  data  must  be  processed  at  a  node  that  has  the  systems  to  do  the  processing.  In  a 
strike  group,  intelligence  data  processing  takes  place  on  the  aircraft  carrier.  If  the  raw 
data  initially  came  from  the  sensors  on  a  destroyer  then  the  data  is  transmitted  from  the 
destroyer,  processed  at  the  hub  (aircraft  carrier),  and  made  available  in  a  data  center 
residing  on  the  hub.  The  raw  data,  now  processed  into  usable  intelligence  infonnation, 
may  be  needed  by  a  cruiser  to  launch  a  surface  missile.  Now  the  data  must  be  made 
available  to  the  cruiser,  which  would  be  pushed  from  the  hub. 

2  The  table  is  a  redacted  form  of  the  table  from  [27],  Appendix  D. 
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Generally,  data  would  reside  on  the  hub  because  the  hub  will  have  the  largest  data 
center(s)  and  the  hub  has  the  systems  to  process  raw  data  into  intelligence.  Edge  clouds 
would  collect  data  from  their  sensors  and  transmit  it  to  the  hub,  and  the  hub  in  turn 
processes  and  stores  this  data,  making  it  available  to  the  entire  strike  group.  Figure  27 
illustrates  this  process.  (For  concepts  on  metadata  formats  for  multi-INT  data  extraction 
from  sensors,  that  could  be  stored  in  these  clouds,  see  “Metadata  Standards  for  Multi-INT 
Fusion  in  Distributed  ISR  Systems”  by  LCDR  Trevor  Day,  a  former  NPS  student.) 

Data  created  within  each  edge  cloud  will  be  stored  internally  in  its  own  data 
center.  That  is,  basic  data  such  as  user  accounts  and  records,  emails,  PowerPoints,  and 
any  other  typical  data  encountered  on  the  regular  day  to  day  operations  of  a  ship  that  can 
be  processed  via  the  CRUD  computer  programming  functions  (Create,  Read,  Update,  and 
Delete). 

Data  received  from  outside  the  hub’s  organic/inorganic  sensors  (i.e.,  from  a  shore 
facility  via  satellite)  -  including  the  edge  clouds  -  will  be  ingested  and  stored  in  a  data 
center  in  the  hub.  The  hub  can  then  transmit  the  data  to  the  requisite  edge  clouds  as 
needed  over  whichever  method  of  communication  links  the  strike  group  is  operating  on 
(such  as  WiMAX).  Again,  having  the  hub  as  the  sole  satellite  receiving  node  is  done  to 
reduce  satellite  use. 

This  does  not  imply  other  ships  will  not  use  satellites.  When  in  a  multi-ship 
environment,  however,  having  one  ship  with  the  capability  to  receive  data,  store  it,  and 
disseminate  it  to  linked  edge  clouds  will  inhibit  satellite  saturation.  This  is  achieved  by 
making  data  available  in  one  centralized  location  (the  hub),  creating  a  situation  in  which 
other  ships  will  not  have  to  access  the  data  through  a  satellite. 
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Figure  27.  Possible  data  storage  process  afloat 


C.  CLOUD-TO-CLOUD  INTEROPERABILITY 

System-to-system  interoperability  has  been  and  continues  to  be  a  challenge  for  the 
Navy  and  the  DoD.  New  information  systems  may  not  be  designed  to  integrate  with  other 
systems,  resulting  in  “stove-pipe”  systems.  A  stove-pipe  system  does  not  share  data  or 
functionality  with  other  systems.  As  a  result  data  may  have  to  traverse  several  networks 
or  nodes  in  order  to  reach  its  destination,  or  the  receiving  system  may  have  to  rely  on  a 
completely  separate  system  to  convert  data  into  a  format  readable  by  the  intended 
recipient  system.  The  route  data  travels  or  the  number  of  times  data  must  be  converted  as 
it  travels  from  origin  to  destination  can  be  an  unnecessary  and  preventable  waste  of  time 
and  resources. 

The  sharing  of  data  between  information  systems  can  be  referred  to  as  portability. 
Portability  of  data  between  systems  is  directly  related  to  the  mobility  of  the  same  data 
between  systems.  Interoperability  between  systems  dictates  the  portability  and  mobility 
of  data.  Cloud  computing  is  highly  dependent  on  the  portability  and  mobility  of  data, 
hence  the  necessity  of  loose  coupling  between  systems  in  any  cloud  computing 
infrastructure.  To  ensure  the  sharing  of  data  from  one  cloud  node  to  another  cloud  node 
in  a  multi-ship  environment,  cloud  to  cloud  interoperability  needs  to  be  addressed. 
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1.  Levels  of  Information  System  Interoperability  Maturity  Model 

A  relevant  model  designed  to  determine  and  classify  levels  of  interoperability 
between  systems  is  the  Levels  of  Information  System  Interoperability  (LISI)  Maturity 
Model  by  the  DoD  C4ISR  Working  Group.  [47]  The  LISI  model  is  a  “formal  Reference 
Model,  an  assessment  implementation  of  the  interoperability  maturity  model,  and  a 
structured  process  for  improving  interoperability  between  varied  infonnation  systems.” 
[48]  As  such,  the  LISI  model  provides  the  “how  to”  in  systems  architecture  development 
and  in  linking  systems.  [49] 

Four  attributes  of  the  LISI  model  define  how  data  is  shared  between  systems: 
procedures,  application,  infrastructure,  and  data  (aka  PAID,  see  Figure  28).  The 
procedures  attribute  refers  to  the  degree  of  interoperability  as  a  result  of  policies, 
processes,  and  the  compliance  of  technical  and  system  architecture  standards.  [50]  The 
application  attribute  defines  the  ability  of  software  applications  to  work  on  different 
systems,  while  the  infrastructure  attribute  defines  the  degree  of  connectivity  between 
systems  and  applications.  The  data  attribute  “reflects  the  flexibility  of  the  data  fonnat  and 
the  richness  of  the  information  being  exchanged  across  systems  and  domains.”  [50] 

Furthermore,  the  ISIL  model  defines  five  maturity  levels  of  system  to  system 
interoperability.  They  are  listed  below.  [49] 

Level  0:  Isolated.  Systems  have  no  connection  to  each  other. 

Level  1 :  Connected.  Systems  are  linked  electronically,  generally  peer-to-peer. 

Level  2:  Functional.  Systems  operate  on  a  distributed  local  network. 

Level  3:  Domain.  Systems  are  capable  of  being  connected  via  a  WAN. 

Level  4:  Enterprise.  Systems  are  capable  of  using  a  distributed  global  infonnation 

space  across  multiple  domains. 

A  cloud  computing  infrastructure  set  in  an  afloat  environment  would  have  to 
fulfill  the  maturity  level  of  three,  at  a  minimum.  At  this  level,  a  strike  group  would  be 
enabled  with  data  sharing  over  a  WAN,  capable  of  sharing  data  over  distances  greater 
than  LOS  and  allowing  multiple  users  to  access  shared  data.  Optimally,  afloat  cloud 
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architectures  would  strive  to  become  a  robust  Level  4  maturity  level,  being  able  to 
connect  to  DoD  and  Naval  network  enterprises,  in  particular  the  Global  Information  Grid. 
If  afloat  cloud  nodes  are  to  ride  on  the  (future)  CANES  infrastructure,  then  Level  4 
should  be  a  goal  to  achieve. 

The  LISI  model  was  written  in  1997  and  at  that  time  cloud  computing  was  still 
just  an  idea.  A  revised  LISI  model  would  likely  need  to  be  completed  in  order  to  address 
the  revolutionary  service  delivering  technology  that  is  cloud  computing.  An  IEEE  paper 
published  in  2011  titled  “Cloud  to  Cloud  Interoperability”  addresses  the  applicability  of 
the  LISI  model  to  cloud  computing  and  makes  several  suggestions  on  how  the  LISI 
model  can  be  updated  to  assess  the  maturity  of  cloud-to-cloud  interoperability.  [50] 
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Figure  28.  The  Levels  of  Information  System  Interoperability  Maturity  Model  [49] 


In  [50],  Barreto,  et  ah,  agree  that  portability  and  mobility  are  “prime  indicators” 
of  the  degree  of  interoperability  between  clouds,  and  believe  open  standards  for  VMs  and 
cloud-to-cloud  APIs  and  advancement  in  virtualization  technologies  will  be  required  for 
successful  cloud  to  cloud  interoperability.  These  statements  are  applicable  to  the  afloat 
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cloud  environment,  particularly  considering  that  each  ship’s  onboard  cloud  infrastructure 
is  built  on  a  virtual  desktop  infrastructure. 

The  difficulties  in  making  clouds  interoperable  are  not  trivial.  Each  ship  will  have 
its  own  unique  cloud;  no  two  ships  in  the  Navy  are  exactly  the  same.  An  example  is  the 
Aegis  Baseline,  the  software  version  of  the  Aegis  weapons  system.  Often,  ships  will  have 
varying  versions  of  the  Baseline.  This  can  cause  complications  when  ships  are  operating 
in  the  same  AOR  and  the  Aegis  systems  try  to  communicate.  Like  the  Aegis  Baseline, 
ships  with  their  own  unique  cloud  will  likely  encounter  problems  when  attempting  to 
share  data  with  other  clouds  that  are  not  similar. 

As  cloud  computing  becomes  more  prominent  in  business,  industry,  the  military, 
etc.,  organizations  will  develop  their  own  cloud  enterprises  that  have  their  own  unique 
characteristics  and  use  specific  standards.  Granted,  cloud  computing  is  typically  designed 
around  web  services,  intended  for  the  primary  purpose  of  leveraging  the  Internet,  and 
therefore  should  all  use  the  same  standards.  The  issue  lies  within  each  organization  and 
the  standards,  equipment,  technologies,  etc.,  that  they  will  use  within  their  organization. 
Variations  within  each  of  these  categories  will  cause  interoperability  issues  like  those 
exhibited  in  the  example  of  the  Aegis  Baseline. 

Listed  below  are  suggested  attributes  that  should  be  characteristic  in  any  cloud  to 
ensuring  cloud  to  cloud  interoperability  [50]: 

•  Portability  of  data,  i.e.,  data  in  a  fonnat  readable  by  all  systems  within  a 
cloud  architecture.  Loose  coupling  or  the  encapsulation  of  data  may  be 
suitable  methods  of  portability. 

•  Mobility  of  data,  or  “the  ability  to  move  a  live  computer  workload  from 
one  host  to  another  without  losing  client  connections  or  in-flight  state.” 
[50] 

•  Applying  SOA  principles  to  help  cloud  to  cloud  integration.  CANES  will 
be  of  great  assistance  in  this  process  considering  it  will  be  based  on  SOA. 
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•  A  well-defined  cloud  security  policy  across  all  clouds  within  a  strike 
group  domain. 

•  Establishment  of  formal  trust  relationships  between  clouds. 

•  A  unifonn  tool  set  to  provision  services  automatically  and  to  manage  VM 
instances. 

In  [50],  additions  to  the  LISI  model’s  PAID  attributes  are  suggested  to  further 
develop  cloud  to  cloud  interoperability: 

•  Procedures:  Unifonn  security  and  privacy  policies.  These  must  be  applied 
consistently  across  all  cloud  boundaries. 

•  Application:  The  ability  of  software  applications  to  “work  and  migrate 
seamlessly  across  cloud  boundaries.”  [50]  Additionally,  a  set  QoS  would 
have  to  be  maintained. 

•  Infrastructure:  This  attribute  helps  maintain  cloud  mobility  and  the  degree 
of  cloud-services  provisioning,  management,  monitoring,  reporting  and 
auditing. 

•  Data:  Shift  from  application-centric  to  data-centric  view  of  infonnation 
processing.  Data  in  the  cloud  must  be  treated  as  artifacts,  artifacts  being 
the  embodiments  of  data.  Users  can  manipulate  this  data,  and  the  benefit 
of  data  as  artifacts  is  that  it  provides  a  uniform  manner  in  which  systems 
can  access  the  data. 

Characteristics  like  those  listed  above  will  be  necessary  to  support  cloud  to  cloud 
interoperability  in  an  afloat  cloud  computing  infrastructure.  The  point  of  utilizing  cloud 
architectures  in  an  afloat  environment  is  to  provide  cloud  services  capable  of  sharing  data 
between  ships.  To  do  so,  data  must  have  the  ability  to  be  accessed  and  manipulated  by 
the  systems  in  the  entire  cloud  enterprise  (manipulated  meaning  data  is  able  to  meet  the 
basic  CRUD  computer  programming  functions).  Furthermore,  ships  in  a  strike  group 
should  be  equipped  with  the  same  infonnation  systems,  use  the  same  standards  and 
policies  throughout  the  cloud  enterprise,  and  offer  the  same  cloud  services.  Doing  so  will 
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help  to  achieve  semantic  and  syntactic  cloud  interoperability  specifically,  and  will 
promote  cloud  to  cloud  interoperability  in  general. 

To  some  extent  ships  will  have  many  of  the  standards  and  resources  to  store  cloud 
data  when  utilizing  a  VDI  like  the  one  built  in  Chapter  III.  Those  VDIs  contain  a 
virtualized  pool  of  storage  in  its  datacenter  and  offer  resource  agility,  scalability,  and 
elasticity.  Hard  disk  drives  can  easily  be  added  or  removed  and  hard  disk  space  will  scale 
when  necessary  to  meet  increasing  volumes  of  infonnation. 

Linking  clouds,  cloud  to  cloud  interoperability,  and  cloud  data  storage  rely  on 
physical  computer  and  network  systems.  These  systems  would  not  operate  without  the 
human  role  of  governance.  The  next  section  discusses  the  command  and  control 
architecture  that  would  be  required  in  an  afloat  cloud  computing  environment. 

D.  AFLOAT  CLOUD  COMMAND  AND  CONTROL  STRUCTURE 

Governance  in  cloud  computing  includes  people  and  processes,  not  just 
technology.  To  ensure  cloud  technology  operates  correctly,  the  support  of  the  people  who 
will  build,  control,  and  monitor  the  cloud  computing  infrastructure  is  important.  [8] 
Likewise,  governance  includes  management-level  visibility  into  the  cloud  infrastructure 
in  afloat  environments,  important  for  the  oversight  of  the  people  implementing  the 
processes.  Governance  is  necessary  for  designing  and  implementing  policies,  and  to 
provide  “command,  control,  discovery,  and  monitoring  as  well  as  design  and 
development  support  for  [cloud]  services.”  [8] 

Governance  of  afloat  cloud  environments  will  be  determined  by  a  command  and 
control  (C2)  structure.  Each  strike  group  has  an  organizational  C2  structure  delineating 
the  chain  of  command,  encompassing  all  ships  belonging  to  the  strike  group.  Before  a 
strike  group  deploys,  specific  Concept  of  Operations  and  Operational  Plans  are 
promulgated  by  the  applicable  authority  for  each  warfare  area,  designating  certain 
responsibilities  to  assets  in  the  strike  group.  A  portion  of  these  responsibilities  establishes 
warfare  commanders  under  the  Composite  Warfare  Commander  (CWC)  concept.  One  of 
the  warfare  commanders  is  the  Force  Over-the-Horizon  track  coordinator,  or  FOTC. 
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As  stated  in  NTTP  6-02,  the  FOTC  is  the  key  process  in  which  “all  information  is 
evaluated  at  a  central  node  before  being  disseminated.”  [51]  In  an  afloat  cloud 
environment  the  FOTC  participates  in  C4I  planning  and  would  be  the  appropriate  warfare 
coordinator  responsible  for  the  operation  of  the  cloud  infrastructure.  Traditionally,  the 
FOTC  resides  on  the  aircraft  carrier  in  a  strike  group,  which  is  suitable  given  the  aircraft 
carrier  is  also  the  hub  in  the  afloat  cloud  infrastructure  as  presented  in  previous  sections. 

Overseeing  the  intelligence  and  network  operations  of  the  strike  group  is  the 
N2/N6  staff  officer.  The  N2/N6,  like  the  FOTC,  participates  in  C4I  planning  and  is 
embarked  on  the  aircraft  carrier.  Together,  the  N2/N6  and  the  FOTC  would  be  the  senior 
officers  responsible  for  the  afloat  cloud  network.  Policy  would  generally  be  promulgated 
by  the  N2/N6,  while  the  FOTC  would  execute  the  policy  while  the  strike  group  is 
operational.  At  the  operational  level  onboard  the  aircraft  carrier  (the  hub),  the 
communications  officer  (COMMO)  and  the  Information  Systems  Officer  (ISO)  would 
together  implement  cloud  policy  on  behalf  of  the  FOTC.  Figure  29  depicts  a  notional 
standard  C2  structure  at  the  force  level. 


Figure  29.  Notional  force  level  (hub)  cloud  C2  structure 

The  C2  structure  at  the  unit  level  (Figure  30)  would  be  very  similar  to  the  force 
level  structure.  Unit  level  ships  such  as  a  DDG  or  CG  do  not  have  a  FOTC  or  an  N2/N6 
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staff  officer  embarked  as  there  is  only  one  of  each  in  the  entire  strike  group.  Unit  level 
ships  will  have  a  COMMO  responsible  for  overall  operations  in  the  radio  room,  including 
the  ship’s  internal  networks  and  all  communication  channels  and  systems  (HF,  UHF, 
SHF,  etc.).  Often,  an  ISO  is  billeted  on  a  unit  level  ship.  In  this  case  the  ISO  assists  the 
COMMO,  either  sharing  responsibilities  tasked  to  the  COMMO  or  fulfilling  roles 
normally  assigned  to  the  COMMO.  IT  personnel  work  for  both  the  COMMO  and  the 
ISO,  with  the  COMMO  being  the  senior  officer. 


Figure  30.  Notional  unit  level  (edge  cloud)  C2  structure 

In  sum,  governance  is  necessary  to  control  and  monitor  the  cloud  services  that 
make  up  an  afloat  cloud  architecture.  At  the  force  level,  the  FOTC  and  the  N2/N6  share 
responsibilities  of  the  afloat  cloud  architecture,  while  at  the  unit  level  the  COMMO  is 
responsible.  The  implementation  of  SOA  into  the  cloud  architecture  will  reflect  the 
policies  and  control  of  the  FOTC  and  COMMO.  In  enterprise  architecture,  governance 
means  “control,  or  the  ability  to  mandate  the  use  of  standards  and  approaches,”  while  in 
the  world  of  SOA  governance  means  “designing,  building,  testing,  and  implementing 
policies  for  services  and  monitoring  their  use.”  Governance  in  afloat  cloud  computing 
should  encompass  these  definitions,  and  the  FOTC  and  COMMO  should  adhere  to  them. 
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V.  CONCLUSION 


A.  SUMMARY 

Overall,  this  thesis  expressed  the  need  for  cloud  computing  in  afloat  naval 
environments  because  of  the  benefits  cloud  computing  offers  and  because  the  Federal 
Government  has  mandated  a  “Cloud  First”  policy  regarding  federal  IT  enterprises.  The 
discussion  on  the  need  for  cloud  computing  in  afloat  environments  specifically  stems 
from  the  request  by  PEO-C4I  for  research  on  cloud  computing  afloat. 

Following  the  need  for  cloud  computing,  a  literature  review  was  carried  out  to 
understand  concepts,  definitions,  and  tenninology  relevant  to  this  thesis.  Current  Navy 
network  programs  and  initiatives  were  discussed  and  the  implications  and  possibilities 
they  present  regarding  their  potential  integration  with  cloud  computing  infrastructures 
were  examined.  The  design  and  implementation  of  a  VDI  in  the  NPS  Cloud  Lab  provided 
a  generic  approach  on  how  to  build  a  VDI  for  a  naval  asset  in  an  afloat  environment.  The 
VDI  was  then  scaled  out  to  include  a  cloud  computing  CONOPS  for  a  multi-ship 
environment. 

This  thesis  proposed  several  ideas  on  what  a  cloud  computing  infrastructure  may 
look  like  in  an  afloat  environment.  The  first  part  focused  on  server  consolidation  and 
virtual  desktop  infrastructures,  which  hosts  desktop  operating  systems  on  virtual 
machines.  By  consolidating  servers  into  blade  servers  the  physical  network  footprint  is 
reduced  as  a  result.  Blade  servers  are  robust  and  scalable  enterprise  platforms  and  are 
suitable  for  cloud  computing  enterprises. 

Virtual  desktop  infrastructures  utilize  virtualization  to  create  virtual  machines. 
Virtual  machines  are  then  accessible  to  users  via  devices  such  as  thin  clients  or  zero 
clients,  which  replace  conventional  desktop  computers.  Virtual  machines  are  hosted  on 
servers,  such  as  blade  servers  that  can  host  several  thousand  virtual  machines. 
Virtualization  benefits  include  datacenter  automation,  reduction  in  capital  costs  via  the 
increase  in  energy  efficiency,  maximization  of  hardware  resources,  and  ease  of  enterprise 
desktop  management. 
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The  VDI  built  in  the  Cloud  Lab  at  NPS  serves  as  a  notional  model  for  integration 
onto  naval  ships,  replacing  the  typical  client-server  model.  With  a  VDI,  aggregated 
resources  form  a  uniform  set  of  elements  that  can  be  managed  like  a  shared  utility  and 
dynamically  provisioned  out  to  virtual  machines  demanding  resources.  Resources  are 
elastic,  provided  to  users  when  needed. 

A  VDI  designed  to  meet  user  needs  and  properly  integrated  into  a  ship’s  network 
infrastructure  offers  a  cloud  computing  enterprise  network  foundation  that  is  agile, 
elastic,  and  scalable.  Desktops  are  streamed  to  users  over  the  shipboard  network, 
delivering  a  unique  cloud  service  -  desktop-as-a-service,  and  management  is  centralized 
in  one  server  that  presides  over  the  entire  VDI.  In  short,  a  VDI  is  a  suitable  foundation 
for  a  shipboard  level  cloud  computing  architecture. 

The  second  part  of  this  thesis  moved  beyond  the  shipboard  level  and  focused  on 
afloat  cloud  computing  infrastructures  in  a  multi-ship  environment.  Several  ideas  were 
proposed  on  how  to  link  clouds,  including  non-satellite  and  satellite  technologies.  One  of 
the  prime  benefits  of  using  cloud  computing  at  sea  is  that  bandwidth,  particularly  satellite 
bandwidth,  is  not  much  of  a  problem  if  data  is  in  a  database  within  the  strike  group.  In  the 
absence  of  satellites,  however,  a  viable  method  of  linking  clouds  is  critical.  This  is  even 
more  so  the  case  when  ships  are  beyond  LOS.  As  suggested  in  this  thesis,  WiMAX  is  a 
promising  solution  to  linking  clouds.  WiMAX  has  a  large  bandwidth  capacity  and  is  very 
fast,  especially  when  the  underpinning  infrastructure  is  4G. 

Linking  clouds  is  a  part  of  determining  what  an  afloat  cloud  infrastructure  looks 
like,  but  where  data  is  actually  stored  will  be  more  of  an  infrastructure  determinant.  Each 
ship  will  have  its  own  datacenter,  outfitted  with  large  pools  of  virtualized  storage 
resources  in  the  VDI.  Data  sharing  is  a  crucial  part  of  afloat  naval  operations  and  making 
it  accessible  is  a  critical  piece  of  the  data  storage  process.  A  single  point  of  ingest  and 
dissemination  of  data  from  shore  facilities  and  from  satellites  at  the  hub  reduces  satellite 
use  from  other  ships  in  the  strike  group.  Another  important  piece  of  the  data  process  is 
the  systems  that  process  data  into  usable  intelligence.  The  hub  is  therefore  a  suitable 
solution  for  being  the  primary  place  of  storage  given  its  large  datacenters  and  that  it 
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Clouds  within  a  strike  group  must  be  interoperable  for  data  sharing  to  take  place. 
This  thesis  suggested  the  Levels  of  Infonnation  Systems  Interoperability  (LISI)  Maturity 
Model  as  a  relevant  model  for  systems  interoperability.  Several  attributes  and 
characteristics  from  the  LISI  Maturity  Model  are  listed  and  defined.  Portability,  mobility, 
SOA  principles,  trust  relationships,  and  uniform  tool  sets  are  just  some  of  the  many 
characteristics  that  individual  and  perhaps  dissimilar  clouds  should  adopt  when  they  are 
to  integrate  and  fonn  one  large,  interoperable  cloud  computing  environment. 

The  last  section  regarding  afloat  cloud  architectures  discussed  a  possible  afloat 
cloud  command  and  control  structure.  Cloud  computing  governance  does  not  just  cover 
system  governance,  but  also  encompasses  the  human  factor.  When  an  afloat  cloud 
infrastructure  is  built  there  will  be  a  need  for  human  operators.  Promulgation  of  C4I 
planning  for  a  strike  group  is  conducted  at  the  force  level.  Officers  included  at  this  level 
are  the  N2/N6  (Intelligence/C4I)  and  the  FOTC.  Together,  these  authority  positions  are 
suitable  for  creating  and  executing  policies  and  plans  relative  to  an  afloat  cloud 
computing  infrastructure.  At  the  unit  level,  the  COMMO  and  the  ISO  (when  applicable) 
would  be  the  practical  operators  of  the  cloud  infrastructure  given  that  they  are  responsible 
for  all  other  computer  networks  and  communication  systems  on  a  ship. 

Cloud  computing  presents  a  paradigm  shift  in  the  way  IT  services  are  provided 
over  networks.  When  cloud  computing  is  combined  with  virtualization  the  benefits  to  an 
IT  enterprise  are  many,  including: 

•  Consolidation  of  disparate  resources 

•  Consolidation  of  servers  leading  to  a  reduction  in  the  network  footprint 

•  Greater  system  to  system  interoperability  via  loose  coupling 

•  Resource  elasticity  and  system  scalability 

Benefits  of  particular  importance  to  the  Navy  include: 

•  Cost  reduction  in  hardware,  software,  manning,  and  more  ($B  in  savings) 

•  Energy  efficiency 

•  Potential  increase  in  bandwidth  efficiency  and  a  reduction  in  satellite 
saturation 

•  Brings  data  to  the  tactical  edge,  practically  eliminating  reach  back 
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The  Department  of  Defense  currently  offers  cloud  services  through  DISA  to  shore 
facilities.  Experiments  with  cloud  computing  in  afloat  environments  have  so  far  been 
limited,  but  there  have  been  and  continues  to  be  experiments  and  the  move  toward  cloud 
computing  in  afloat  environments  is  gaining  traction.  PEO-C4I  and  SPAWAR  are 
actively  researching  cloud  computing  for  the  purpose  of  using  cloud  architectures  at  sea. 
This  thesis  maps  to  several  NPS  thesis  topics  PEO-C4I  has  provided  by  the  NPS  C4I 
chair.  In  2009  a  company  called  Dataline  LLC  demonstrated  that  a  “standard  shipboard 
communications  infrastructure  could  be  used  to  manage  a  commercial  cloud  computing 
infrastructure  as  a  service  (IaaS)  platform.”  [52] 

The  near  future  role  out  of  the  CANES  initiative,  which  is  based  on  SOA,  places 
cloud  computing  only  steps  away  from  fleet  implementation.  IaaS  will  be  provided  by 
CANES,  while  PaaS  and  desktops-as-a-service  can  be  provided  by  a  VDI  such  as  the  one 
built  in  this  thesis.  With  the  CANES  initiative  and  the  tangible  benefits  listed  above, 
afloat  cloud  computing  network  enterprises  should  sound  very  promising  to  the  Navy. 

B.  FUTURE  RESEARCH 

Utilization  of  cloud  computing  is  growing,  expanding  into  many  types  and  areas 
of  companies,  organizations,  governments  and  militaries.  This  thesis  focused  on  cloud 
computing  in  afloat  naval  environments.  Limited  in  scope,  several  aspects  of  cloud 
computing  were  not  research  or  discussed.  One  aspect  vital  to  military  operations  is 
security,  which  was  not  discussed  in  this  thesis.  Security  in  cloud  computing  is  a  topic 
deserving  of  in-depth  research.  Implementing  cloud  computing  introduces  new  security 
vulnerabilities  that  need  to  be  understood  and  addressed.  When  researching  for  this  thesis 
much  of  the  reference  material  included  polls  asking  organizations  to  list  their  concerns 
about  moving  their  IT  infrastructure  to  a  cloud  based  enterprise.  In  almost  every  case 
security  topped  the  list. 

This  thesis  proposed  several  concepts  and  implemented  a  VDI,  but  did  not  include 
physical  testing  of  all  that  was  proposed.  Field  experiments  on  linking  clouds  using  any 
of  the  technologies  listed  in  this  thesis  (such  as  LTA  ships,  WiMAX,  BGAN)  provides 
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plenty  of  opportunities  for  future  research.  The  same  is  true  for  testing  cloud-to-cloud 
interoperability. 

The  VDI  built  in  the  NPS  Cloud  Lab  did  not  use  several  of  the  virtualization 
products  or  cloud  computing  products  offered  by  VMware.  Products  such  as  vCloud 
Director,  vCloud  Connector,  or  the  newest  version  of  vSphere  ESXi  (version  5.0)  were 
not  used.  Use  of  these  products  likely  offers  better  cloud  computing  and  virtualization 
perfonnance  and  more  configuration  options  with  greater  benefits  than  were  achieved 
with  the  products  and  versions  used.  Scaling  the  VDI  to  include  tactical  applications  is 
another  future  research  need,  especially  if  cloud  computing  becomes  the  standard  in 
afloat  network  environments. 

Cyber  defense  and  cyber  warfare  applications  will  likely  need  research  in  cloud 
computing  architectures  and  cloud  computing  concepts  of  operations.  Ultimately, 
understanding  future  cloud  infrastructures  developed  in  industry  is  an  area  of  research  to 
detennine  how  to  best  leverage  cloud  computing  in  the  DoD. 
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